ETSI TS 101 377-4-7 V1.1.1 (2001-03) 



Technical Specification 



GEO-Mobile Radio Interface Specifications; 
Part 4: Radio interface protocol specifications; 
Sub-part 7: Mobile radio interface Layer 3 Specifications; 

GMR-2 04.008 



GMR-2 04.008 2 ETSI TS 1 01 377-4-7 V1 .1 .1 (2001 -03) 



Reference 
DTS/SES-002-04008 

Keywords 

GMR, MSS, MES, satellite, S-PCN, GSM, 
interface, layer 3, mobile, radio 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 



Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 

Siret N°348 623 562 00017 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N ° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.ora 

The present document may be made available in more than one electronic version or in print. In any case of existing or 
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 
Information on the current status of this and other ETSI documents is available at http://www.etsi.orq/tb/status/ 

If you find errors in the present document, send your comment to: 

editor@etsi.fr 

Copyright Notification 



No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2001. 
All rights reserved. 



ETSI 



GMR-2 04.008 



3 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



Contents 

Intellectual Property Rights 16 

Foreword 18 

Introduction 19 

1 Scope 20 

1 . 1 General 20 

1 .2 Application to the hiterface Structures 20 

1.3 Structure of Layer 3 Procedures 20 

1.4 Use of Logical Channels 20 

1 .5 Overview of Control Procedures 21 

1.5.1 List of Procedures 21 

2 References 23 

3 Definitions and abbreviations 26 

3.1 Definitions 26 

3.2 Abbreviations 27 

4 Radio resource management procedures 27 

4.1 Overview 27 

4.1.1 General 27 

4. 1.2 Services provided to upper layers 27 

4.1.2.1 Idle mode 27 

4.1.2.2 Establishment and release of a RR connection 27 

4.1.2.3 RR connected mode 28 

4.1.3 Services required from data link and physical layers 28 

4.1.4 Change of dedicated channels 28 

4.1.4.1 Change of dedicated channels using SAPl = 28 

4. 1.4.2 Change of dedicated channels using other SAPls than 28 

4. 1 .4.3 Sequenced Message Transfer Operation 29 

4. 1 .4.3. 1 Variables and Sequence Numbers 29 

4.1.4.3.1.1 Send State Variable V(SD) 29 

4. 1.4.3. 1.2 Send Sequence Number N(SD) 29 

4.1.4.3.2 Procedures for the initiation, transfer execution and termination of the sequenced message 
transfer operation 29 

4.1.4.3.2.1 Initiation 29 

4. 1.4.3.2.2 Transfer Execution 29 

4.1.4.3.2.3 Termination 29 

4.1.5 Procedure for Service Request and Contention Resolution 30 

4.2 Idle mode procedures 30 

4.2.1 MESside 30 

4.2.2 Network Side 31 

4.2.2.1 System Information Broadcasting 31 

4.2.2.1.1 Broadcast of System Information Messages on the S-BCCH 32 

4.2.2. 1.2 Broadcast of System Information Messages on the S-HBCCH 32 

4.2.2.2 Paging 34 

4.3 RR connection establishment 35 

4.3.1 RR connection establishment initiated by the MES: Immediate assignment procedure 35 

4.3.1.1 Permission to Access the Network 35 

4.3.1.2 Initiation of the Immediate Assigrmient Procedure 35 

4.3.1.3 Answer from the network 36 

4.3. 1 .3. 1 Receipt of a CHANNEL REQUEST message 36 

4.3.1.3.2 Assignment rejection 37 

4.3.1.4 Assignment completion 37 

4.3.1.5 Abnormal Cases 37 

4.3.2 Paging procedure 37 

4.3.2. 1 Paging initiation by the network 37 



ETSI 



GMR-2 04.008 



4 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



4.3.2.1.1 S-HPACH logical channel use 38 

4.3.2.1.2 S-PCH logical channel use 38 

4.3.2.1.3 Paging process 38 

4.3.2.2 Paging response 40 

4.3.2.3 Abnormal cases 43 

4.4 RR Connection Transfer Phase 44 

4.4. 1 S-SACCH procedures 44 

4.4.1.1 General 44 

4.4. 1 .2 Measurement report 44 

4.4.2 Transfer of messages and hnk layer service provision 44 

4.4.3 Channel assigimient procedure 44 

4.4.3.1 Channel assignment initiation 45 

4.4.3.2 Assignment completion 45 

4.4.3.3 Abnormal cases 45 

4.4.4 Handover procedure 46 

4.4.5 Frequency redefinition procedure 46 

4.4.6 Channel mode modify procedure 46 

4.4.6. 1 Initiation of the channel mode modify procedure 46 

4.4.6.2 Completion of mode change procedure 46 

4.4.6.3 Abnormal cases 46 

4.4.7 Ciphering mode setting procedure 46 

4.4.7. 1 Ciphering mode setting initiation 46 

4.4.7.2 Ciphering mode setting completion 47 

4.4.8 Additional channel assignment procedure 47 

4.4.9 Partial channel release procedure 47 

4.4. 10 Classmark change procedure 47 

4.4. 1 1 Classmark interrogation procedure 47 

4.4. 1 1 . 1 Classmark interrogation initiation 47 

4.4. 1 1 .2 Classmark interrogation completion 48 

4.5 RR connection release procedure 48 

4.5. 1 Normal release procedure 48 

4.5.1.1 Channel Release Procedure Initiation 48 

4.5.1.2 Abnormal cases 48 

4.5.2 Radio link failure 48 

4.5.2.1 Mobile side 49 

4.5.2.2 Network side 49 

4.5.3 RR connection abortion 49 

4.6 Receiving a RR STATUS message by a RR entity 49 

5 Elementary procedures for mobility management 50 

5.1 General 50 

5.1.1 Type of MM Procedures 50 

5.1.2 MM sublayer states 50 

5. 1.2. 1 MM sublayer states in the MES 50 

5.1.2.1.1 Main states 51 

5.1.2.1.2 Substates of the MM idle state 53 

5.1.2.2 Update status 53 

5.1.2.3 MM sublayer states on the network side 54 

5.2 Behaviour in MM IDLE state 54 

5.2.1 Primary service state selection 55 

5.2. 1 . 1 Selection of the service state after power on 55 

5.2.1.2 Other cases 55 

5.2.2 Detailed description of the MES behaviour in MM IDLE state 55 

5.2.2. 1 Service state, NORMAL SERVICE 56 

5.2.2.2 Service state, ATTEMPTING TO UPDATE 56 

5 .2.2.3 Service state, LIMITED SERVICE 56 

5.2.2.4 Service state, NO IMSI 56 

5.2.2.5 Service state, SEARCH FOR PLMN/PSMN, NORMAL SERVICE 57 

5 .2.2.6 Service state, SEARCH FOR PLMN/PSMN 57 

5.2.3 Service state when back to state MM IDLE from another state 57 

5.3 MM common procedures 58 

5.3. 1 TMSI reallocation procedure 58 



ETSI 



GMR-2 04.008 



5 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



5.3.2 Authentication procedure 58 

5.3.2. 1 Authentication request by the network 58 

5.3.2.2 Authentication response by the MES 58 

5.3.2.3 Authentication processing in the network 58 

5.3.2.4 Ciphering key sequence number 58 

5.3.2.5 Unsuccessful authentication 59 

5.3.2.6 Abnormal cases 59 

5.3.3 Identification procedure 59 

5.3.3.1 Identity request by the network 60 

5.3.3.2 Identification Response by the MES 60 

5.3.3.3 Abnormal Cases 60 

5.3.4 IMSI detach procedure 60 

5.3.5 Abort procedure 60 

5.4 MM specific procedures 60 

5.4. 1 Location updating procedure 61 

5.4.2 Periodic updating 61 

5.4.3 IMSl attach procedure 62 

5.4.4 Generic location updating procedure 62 

5.4.4. 1 Location updating initiation by the MES 62 

5.4.4. la Network request for additional MES capability information 62 

5 .4.4.2 Identification request from the network 62 

5.4.4.3 Authentication by the network 62 

5.4.4.4 Ciphering mode setting by the network 63 

5.4.4.5 Attempt counter 63 

5.4.4.6 Location Updating Accepted by the Network 63 

5.4.4.7 Location updating not accepted by the network 64 

5.4.4.8 Release of RR connection after location updating 64 

5.4.4.9 Abnormal cases on the MES side 65 

5.4.4.10 Abnormal cases on the network side 66 

5.5 Connection management sublayer service provision 66 

5.5.1 MM connection establishment 66 

5.5.1.1 MM connection establishment initiated by the MES 66 

5.5. 1 .2 Abnormal cases 68 

5.5.1.3 MM Connection Establishment Initiated by the Network 69 

5.5.1.4 Abnormal cases 69 

5.5. 1 .5 MM coimection establishment for emergency calls 69 

5.5.1.6 Call re-establishment 70 

5.5.1.7 Forced release during MO MM connection establishment 70 

5.5.2 MM connection information transfer phase 71 

5.5.2. 1 Sending CM messages 71 

5.5.2.2 Receiving CM messages 71 

5.5.2.3 Abnormal cases 71 

5.5.3 MM connection release 71 

5.5.3.1 Release of associated RR connection 71 

6 Elementary procedures for circuit-switched call control 72 

6. 1 Overview 72 

6.1.1 General 72 

6.1.2 Call control states 74 

6.1.2.1 Call states at the user terminal side of the interface 74 

6.1.2.1.1 Null (State UO) 74 

6.1.2.1.2 MM CONNECTION PENDING (State UO.l) 74 

6.1.2.1.3 CALL INITIATED (State Ul) 74 

6. 1 .2. 1 .4 Mobile Originating Call Proceeding (State U3) 75 

6.1.2.1.5 Call Delivered (State U4) 75 

6. 1.2. 1.6 Call Present (State U6) 75 

6.1.2.1.7 Call Received (State U7) 75 

6.1.2.1.8 Connect Request (State U8) 75 

6.1.2.1.9 Mobile Terminating Call Confirmed (State U9) 75 

6.1.2.1.10 Active (State UIO) 75 

6.1.2.1.11 Disconnect Request (State Ull) 75 

6. 1.2. 1. 12 Disconnect Indication (State U12) 75 



ETSI 



GMR-2 04.008 



6 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



6.1.2.1.13 Release Request (State U19) 75 

6.1.2.1.14 Mobile Originating Modify (State U26) 75 

6.1.2.1.15 Mobile Terminating Modify (State U27) 75 

6.1.2.2 Network Call States 76 

6.1.2.2.1 Null (State NO) 76 

6.1.2.2.2 MM CONNECTION PENDING (State NO.l) 76 

6.1.2.2.3 CALL INITIATED (State Nl) 76 

6. 1 .2.2.4 Mobile Originating Call Proceeding (State N3) 76 

6. 1 .2.2.5 Call Delivered (State N4) 76 

6. 1.2.2.6 Call Present (State N6) 76 

6. 1 .2.2.7 Call Received (State N7) 76 

6.1.2.2.8 Connect Request (State N8) 76 

6. 1 .2.2.9 Mobile Terminating Call Confirmed (State N9) 76 

6.1.2.2.10 Active (State NIO) 76 

6.1.2.2.11 (Not Used) 77 

6.1.2.2.12 Disconnect Indication (State N12) 77 

6.1.2.2.13 Release request (State N19) 77 

6. 1 .2.2. 14 Mobile Originating Modify (State N26) 77 

6.1.2.2.15 Mobile Terminating Modify (State N27) 77 

6.1.2.2.16 Connect Indication (State N28) 77 

6.2 Call establishment procedures 77 

6.2. 1 Mobile originating call establishment 78 

6.2.1.1 Call Initiation 78 

6.2. 1 .2 Receipt of a setup message 79 

6.2. 1 .3 Receipt of a CALL PROCEEDING message 79 

6.2. 1 .4 Notification of progressing mobile originated call 80 

6.2. 1 .4. 1 Notification of interworking in connection with mobile originated call establishment 80 

6.2. 1 .4.2 Call progress in the PLMN/ISDN environment 80 

6.2.1.5 Alerting 80 

6.2. 1 .6 Call connected 81 

6.2.1.7 Call rejection 81 

6.2. 1.8 Transit network selection 82 

6.2. 1 .9 Traffic channel assignment at mobile originating call establishment 82 

6.2.1.10 Call Queuing at mobile originating call establishment 82 

6.2.2 Mobile terminating call establishment 82 

6.2.2. 1 Call indication 82 

6.2.2.2 Compatibility checking 83 

6.2.2.3 Call confirmation 83 

6.2.2.3. 1 Response to SETUP 83 

6.2.2.3.2 Receipt of CALL CONFIRMED and ALERTING by the network 83 

6.2.2.3.3 Call failure procedures 85 

6.2.2.3.4 Called MES clearing during mobile terminating call establishment 85 

6.2.2.4 Notification of interworking in connection with mobile terminating call establishment 85 

6.2.2.5 Call accept 85 

6.2.2.6 Active indication 86 

6.2.2.7 Traffic channel assignment at mobile terminating call establishment 86 

6.2.2.8 Call queuing at mobile terminating call establishment 86 

6.2.2.9 User connection attachment during a mobile terminating call 86 

6.2.3 Mobile-to-Mobile Call Establishment, Special Procedures 86 

6.2.3.1 Call Initiation 86 

6.2.3.2 Call Connection 87 

6.3 Signalling procedures during the "Active" state 87 

6.3.1 User notification procedure 87 

6.3.2 Call rearrangements 87 

6.3.3 DTMF protocol control procedure 88 

6.3.3.1 Start DTMF request by the MES 88 

6.3.3.2 Start DTMF response by the network 88 

6.3.3.3 Stop DTMF request by the user terminal 88 

6.3.3.4 Stop DTMF response by the network 88 

6.3.3.5 Sequencing of subsequent start DTMF requests by the MES 88 

6.3.4 Support of Dual Services 89 

6.3.5 Mobile-to-Mobile Signaling Procedures 89 



ETSI 



GMR-2 04.008 7 ETSI TS 1 01 377-4-7 V1 .1 .1 (2001 -03) 

6.4 Call clearing 90 

6.4. 1 Terminology 90 

6.4.2 Exception conditions 90 

6.4.3 Clearing initiated by the MES 90 

6.4.3.1 Initiation of call clearing 90 

6.4.3.2 Receipt of a DISCONNECT message from the MES 91 

6.4.3.3 Receipt of a RELEASE message from the network 91 

6.4.3.4 Receipt of a RELEASE COMPLETE message from the MES 91 

6.4.3.5 Abnormal cases 91 

6.4.3.6 Initiation of Call Clearing, Mobile-to-Mobile Calls 91 

6.4.3.7 Receipt of RELEASE Message by the User Terminal 92 

6.4.3.8 Receipt of RELEASE Message by the Network 92 

6.4.3.9 Receipt of RELEASE COMPLETE Message by the User Terminal 92 

6.4.3.10 Abnormal Cases 92 

6.4.4 Clearing initiated by the network 92 

6.4.4.1 Clearing when tones/announcements provided 92 

6.4.4.2 Clearing when tones/announcements not provided 92 

6.4.4.2. 1 Receipt of a DISCONNECT message without progress indicator or with progress indicator 
different from #8 from the network 93 

6.4.4.2.2 Receipt of a RELEASE message from the MES 93 

6.4.4.2.3 Abnormal cases 93 

6.4.4.3 Completion of clearing 93 

6.4.4.3. 1 Abnormal cases 93 

6.4.5 Clear collision 93 

6.5 Miscellaneous procedures 94 

6.5.1 In-Band tones and announcements 94 

6.5.2 Call collisions 94 

6.5.3 Status procedures 94 

6.5.3.1 Status enquiry procedure 94 

6.5.3.2 Reception of a STATUS message by a CC entity 95 

6.5.3.2.1 STATUS message with incompatible state 95 

6.5.3.2.2 STATUS message with compatible state 95 

6.5.4 Call re-establishment, MES side 95 

6.5.5 Call re-establishment, network side 96 

6.5.6 Progress 96 

7 Support of packet services 96 

8 Examples of structured procedures 96 

8.1 General 96 

8.1.1 Paging request 97 

8.1.2 Immediate assigrraient 97 

8.1.4 Authentication 98 

8.1.5 Ciphering mode setting 98 

8.1.6 Transaction phase 98 

8.1.6.1 Transmission mode change 99 

8.1.7 Channel release 99 

8.2 Abnormal cases 100 

8 . 3 Selected examples 1 00 

8.3.1 Location updating 1 00 

8.3.2 Mobile originating call establishment 101 

8.3.3 Mobile terminating call establishment 102 

8.3.4 Call clearing 104 

8.3.5 DTMF protocol control 106 

8.3.6 Handover 106 

8.3.7 In-call modification 106 

9 Handling of unknown, unforeseen and erroneous protocol data 107 

9.1 General 107 

9.2 Message too short 108 

9.3 Unknown or unforeseen transaction identifier 108 

9.4 Unknown or unforeseen message type 108 

9.5 Non-semantical mandatory information element errors 109 



ETSI 



GMR-2 04.008 



8 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



9.5. 1 Radio resource management 109 

9.5.2 Mobility management 109 

9.5.3 Call control 110 

9.6 Unknown and unforeseen lEs in the non-imperative message part 1 10 

9.6. 1 lEls unknown in the message 1 10 

9.6.2 Out of sequence lEs 110 

9.6.3 Repeated lEs 110 

9.7 Non-imperative message part errors 1 10 

9.7. 1 Syntactically incorrect optional lEs Ill 

9.7.2 Conditional IE errors 1 1 1 

9.8 Messages with semantically incorrect contents Ill 

10 Message functional definitions and contents 1 12 

10.1 Messages for radio resources management 113 

10.1.1 Additional assignment 114 

10.1.2 Assigimient command 114 

10.1.2.1 Mode of the channel 114 

10.1.2.2 Description of the Second Channel 114 

10.1.2.3 Mode of the Second Channel 114 

10.1.2.4 Mobile Allocation and Frequency List, after the starting time 114 

10.1.2.5 Starting Time 114 

10.1 .2.6 Reference cell frequency list 1 14 

10.1.2.7 Cell Channel Description 114 

10.1.2.8 Cipher mode setting 115 

10.1.3 Assignment complete 1 15 

10.1.4 Assignment failure 115 

10.1.5 Channel mode modify 115 

10.1.6 Channel mode modify acknowledge 116 

10.1.7 Channel release 116 

10.1.8 Channel request 116 

10.1.8.1 Random Access (RA) 117 

10.1.8.2 Subscriber IMSI number 117 

10.1.8.3 International number 117 

10.1.8.4 Paging references 118 

10.1.8.5 Satellite Visibility (SV) 118 

10.1.8.6 Attempt Number (AN) 118 

10.1.8.7 Location updating with follow-on 118 

10.1.9 Ciphering mode command 118 

10.1.10 Ciphering mode complete 119 

10.1.10.1 Mobile Equipment Identity 119 

10.1.11 Classmark change 119 

10.1.11.1 Additional MES classmark information 120 

10.1.12 Classmark enquiry 120 

10.1.13 Frequency redefinition 120 

10. 1. 14 Handover access 120 

10.1.15 Handover command 120 

10.1.16 Handover complete 120 

10. 1. 17 Handover failure 120 

10.1.18 Immediate assigimient 121 

10.1.19 Immediate assignment extended 121 

10.1.20 Immediate assignment reject 121 

10.1.20.1 Use of the indexes 122 

10.1.20.2 Filling of the Message 122 

10.1.21 Measurement report 122 

10. 1 .22 Paging Request Type 1 122 

10.1.22.1 Unnecessary IE 123 

10.1.22.2 Channel needed for mobile identity 123 

10.1.22.3 Mobile Identity 123 

10.1.22.4 PI rest octets 123 

10.1.23 Paging request type 2 123 

10.1.24 Paging request type 3 123 

10. 1.25 Paging response 123 



ETSI 



GMR-2 04.008 



9 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



10.1.25.1 Location Area Code 123 

10.1.25.2 Mobile Identity 123 

10.1.26 Partial release 124 

10.1.27 Partial release complete 124 

10.1.28 Physical information 124 

10.1.29 RR status 124 

10.1.30 Synchronization channel information 124 

10.1.31 System information type 1 125 

10.1.32 System information type 2 125 

10. 1.33 System information type 2bis 125 

10.1.34 System information type 3 125 

10.1.35 System information type 3 126 

10.1.36 System information type 4 126 

10.1.37 System information type 5 126 

10.1.38 System information type 5bis 126 

10.1.39 System information type 5ter 126 

10.1 .40 System information type 6 126 

10.1.40.1 Cellldentity 127 

10.1.40.2 Location Area Identification 127 

10.1.40.3 Spotbeam options 127 

10.1.41 System Information Type 7 (GMR-2 option) 127 

10.1.42 System Information Type 8 128 

10.1.43 System Information Type 9 128 

10. 1.44 System Information Type 10 128 

10.1.45 Paging Request-HPACH IMSI 129 

10.1.45.1 Mobile paging identity 129 

10.1.45.2 MES TX Disable/Enable 130 

10.1.46 Transmit Disable 130 

10.1.47 Transmit Disable Acknowledgement 130 

10.1.48 H-BCCH version number 131 

10.2 Messages for mobility management 131 

10.2.1 Authentication reject 132 

10.2.2 Authentication request 132 

10.2.3 Authentication response 133 

10.2.4 CM Re-establishment request 133 

10.2.5 CM service accept 133 

10.2.6 CM service reject 134 

10.2.7 CM service abort 134 

10.2.8 Abort 134 

10.2.9 CM service request 134 

10.2.9.1 Location area code 135 

10.2.9.2 Mobile identity 135 

10.2.10 Identity request 135 

10.2.11 Identity response 135 

10.2.12 IMSI detach indication 136 

10.2. 13 Location updating accept 136 

10.2.13.1 Follow on proceed 136 

10.2.13.2 Mobile identity 136 

10.2.14 Location updating reject 136 

10.2.15 Location updating request 137 

10.2.15.1 Location Area Identification 137 

10.2.15.2 Location Area Code 137 

10.2.15.3 Mobile Identity 137 

10.2.16 MM Status 137 

10.2. 17 TMSI reallocation command 138 

10.2.18 TMSI reallocation complete 138 

10.3 Messages for circuit- switched call control 138 

10.3.1 Alerting 139 

10.3.1.1 Alerting (Network to MES Direction) 139 

10.3.1.1.1 Facility 139 

10.3.1.1.2 Progress indicator 139 

10.3.1.1.3 User -User 139 



ETSI 



GMR-2 04.008 



10 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



10.3. 1 .2 Alerting (MES to Network direction) 139 

10.3.1.2.1 Facility 140 

10.3.1.2.2 User -User 140 

10.3.1.2.3 SS version 140 

10.3.2 Call Confirmed 140 

10.3.2.1 Repeat indicator 141 

10.3.2.2 Bearer capability 1 and bearer capability 2 141 

10.3.2.3 Cause 141 

10.3.2.4 CC Capabilities 141 

10.3.3 Call proceeding 141 

10.3.3.1 Repeat indicator 142 

10.3.3.2 Bearer capability 1 and bearer capability 2 142 

10.3.3.3 Facility 142 

10.3.3.4 Progress indicator 142 

10.3.4 Congestion control 142 

10.3.4.1 Cause 143 

10.3.5 Connect 143 

10.3.5.1 Connect (Network to MES direction) 143 

10.3.5.1.1 Facility 143 

10.3.5.1.2 Progress indicator 143 

10.3.5.1.3 User-User 144 

10.3.5.2.1 Facility 144 

10.3.5.2.2 User-User 144 

10.3.5.2.3 SS version 144 

10.3.6 Connect acknowledge 144 

10.3.7 Disconnect 145 

10.3.7.1 Disconnect (Network to MES direction) 145 

10.3.7.1.1 Facility 145 

10.3.7.1.2 Progress indicator 145 

10.3.7.1.3 User-User 145 

10.3.7.2 Disconnect (MES to Network direction) 145 

10.3.7.2.1 Facility 146 

10.3.7.2.2 User-User 146 

10.3.7.2.3 SS version 146 

10.3.8 Emergency setup 146 

10.3.8.1 Bearer capability 146 

10.3.9 Facility 147 

10.3.9.1 Facility (Network to MES direction) 147 

10.3.9.2 Facility (MES to Network direction) 147 

10.3.9.2.1 SS version 147 

10.3.10 Hold 148 

10.3.11 Hold acknowledge 148 

10.3.12 Hold reject 148 

10.3.13 Modify 149 

10.3.13.1 Low layer compatibility 149 

10.3. 13.2 High layer compatibility 149 

10.3.13.3 Reverse call setup direction 149 

10.3. 14 Modify complete 149 

10.3. 14. 1 Low layer compatibility 150 

10.3. 14.2 High layer compatibihty 150 

10.3.14.3 Reverse call setup direction 150 

10.3.15 Modify reject 150 

10.3.15.1 Low layer compatibihty 150 

10.3.15.2 High layer compatibihty 151 

10.3.16 Notify 151 

10.3.17 Progress 151 

10.3.17.1 User-user 151 

10.3.18 Release 152 

10.3.18.1 Release (Network to MES direction) 152 

10.3.18.1.1 Cause 152 

10.3.18.1.2 Second cause 152 

10.3.18.1.3 Facility 152 



ETSI 



GMR-2 04.008 1 1 ETSI TS 1 01 377-4-7 VI .1 .1 (2001 -03) 

10.3.18.1.4 User-user 152 

10.3.18.2 Release (MES to Network direction) 152 

10.3.18.2.1 Cause 153 

10.3.18.2.2 Second cause 153 

10.3.18.2.3 Facility 153 

10.3.18.2.4 User-user 153 

10.3.18.2.5 SS version 153 

10.3.18.3 Release (MES to MES) 153 

10.3.18.3.1 Cause 154 

10.3.19 Release complete 154 

10.3.19.1.1 Cause 154 

10.3.19.1.2 Facility 154 

10.3.19.1.3 User-user 154 

10.3. 19.2 Release complete (MES to Network direction) 155 

10.3.19.2.1 Cause 155 

10.3.19.2.2 Facility 155 

10.3.19.2.3 User-user 155 

10.3.19.2.4 SS version 155 

10.3. 19.3 Release complete (MES to MES and Network) 155 

10.3.19.3.1 Cause 156 

10.3.20 Retrieve 156 

10.3.21 Retrieve acknowledge 156 

10.3.22 Retrieve reject 157 

10.3.23 Setup 157 

10.3.23. 1 Setup (mobile terminated call establishment) 157 

10.3.23.1.1 BC repeat indicator 158 

10.3.23.1.2 Bearer capability 1 and bearer capability 2 158 

10.3.23.1.3 Facility 158 

10.3.23.1.4 Progress indicator 158 

10.3.23.1.5 Called party subaddress 158 

10.3.23.1.6 LLC repeat indicator 159 

10.3.23. 1 .7 Low layer compatibility 1 159 

10.3.23. 1 .8 Low layer compatibility U 159 

10.3.23.1.9 HLC Repeat Indicator 159 

10.3.23.1.10 High layer compatibihty 1 159 

10.3.23.1.11 High layer compatibihty H 159 

10.3.23.1.12 User-user 159 

10.3.23.1.13 Signal 159 

10.3.23.1.14 Calling party BCD number 159 

10.3.23.1.15 Calling party subaddress 160 

10.3.23.1.16 Called party BCD number 160 

10.3.23.2 Setup (mobile originating call establishment) 160 

10.3.23.2.1 BC repeat indicator 160 

10.3.23.2.2 Facility 160 

10.3.23.2.3 LLC repeat indicator 161 

10.3.23.2.4 Low layer compatibihty 1 161 

10.3.23.2.5 Low layer compatibihty H 161 

10.3.23.2.6 HLC Repeat Indicator 161 

10.3.23.2.7 High layer compatibility 1 161 

10.3.23.2.8 High layer compatibihty H 161 

10.3.23.2.9 User-user 161 

10.3.23.2.10 SS version 161 

10.3.23.2.11 CLIR suppression 161 

10.3.23.2.12 CLIR invocation 162 

10.3.23.2.13 Bearer capability 2 162 

10.3.23.2.14 Calling party subaddress 162 

10.3.23.2.15 Called party subaddress 162 

10.3.23.2.16 CC capabilities 162 

10.3.24 Start DTMF 162 

10.3.25 Start DTMF acknowledge 162 

10.3.25. 1 Keypad facility 163 

10.3.26 Start DTMF reject 163 



ETSI 



GMR-2 04.008 1 2 ETSI TS 1 01 377-4-7 VI .1 .1 (2001 -03) 

10.3.27 Status 163 

10.3.27.1 Auxiliary states 164 

10.3.28 Status enquiry 164 

10.3.29 StopDTMF 164 

10.3.30 Stop DTMF acknowledge 164 

10.3.31 User information 165 

10.3.31.1 User-user 165 

10.3.31.2 More data 165 

1 1 General message format and information elements coding 166 

11.1 Overview 166 

11.2 Protocol Discriminator 166 

11.3 Skip indicator and transaction identifier 1 67 

11.3.1 Skip indicator 1 67 

11.3.2 Transaction identifier 167 

1 1 .4 Message type 167 

11.5 Other Information Elements 171 

11.5.1 Common Information Elements 172 

11.5.1.1 Cell identity 172 

11.5.1 .2 Ciphering Key Sequence Number 173 

11.5.1.3 Location Area Identification 173 

11.5.1.4 Mobile Identity 174 

11.5.1.5 MES Classmark 1 175 

1 1 .5. 1 .6 MES Classmark 2 176 

11.5.1.7 MES Classmark 3 177 

11.5.1.8 Spare half octet 178 

1 1 .5.2 Radio Resource Management Information Elements 179 

11.5.2.1 Void 179 

11.5.2.1a BA range 179 

11.5.2.1b Cell channel description 179 

1 1 .5.2.2 Cell description 179 

11.5.2.3 Spotbeam options 180 

1 1.5.2.4 Spotbeam selection parameters 180 

1 1.5.2.5 Channel description 181 

11.5.2.6 Channel mode 182 

11.5.2.7 Channel Mode 2 183 

11.5.2.8 Channel needed 183 

1 1 .5.2.9 Cipher mode setting 183 

11.5.2.10 Cipher response 184 

11.5.2.11 Control channel description 184 

11.5.2.12 Frequency Channel Sequence 186 

11.5.2.13 Frequency List 186 

11.5.2.14 Frequency Short List 186 

11.5.2.15 Handover Reference 186 

11.5.2.16 LA. Rest Octets 186 

11.5.2.17 lARRest Octets 186 

11.5.2.18 lAX Rest Octets 186 

11.5.2.19 L2 pseudo length 186 

1 1 .5.2.20 Measurement Results 1 87 

11.5.2.21 Mobile Allocation 188 

11.5.2.21a Mobile Time Difference 188 

1 1 .5.2.22 Neighbour spotbeams description 188 

11.5.2.23 PI rest octets 189 

1 1 .5.2.24 P2 Rest Octets 190 

11.5.2.25 P3 Rest Octets 190 

11.5.2.26 Page mode 190 

1 1 .5.2.27 Network Colour Code (NCC) permitted 190 

11.5.2.28 Power command 191 

1 1.5.2.29 S-RACH control parameters 191 

1 1 .5.2.30 Request reference 192 

11.5.2.31 RR cause 193 

11.5.2.32 SI 1 Rest Octets 194 



ETSI 



GMR-2 04.008 1 3 ETSI TS 1 01 377-4-7 VI .1 .1 (2001 -03) 



11.5.2.33 SI 2bis Rest Octets 194 

1 1 .5.2.34 Spotbeam Re-selection Parameters 194 

11.5.2.35 SI 4 Rest Octets 195 

11.5.2.36 SI 7 Rest Octets 195 

11.5.2.37 SI 8 Rest Octets 195 

11.5.2.38 Starting Time 195 

1 1 .5.2.39 Synchronization Indication 195 

1 1 .5.2.40 Fine timing advance 195 

11.5.2.41 Time Difference 196 

11.5.2.42 TMSI 196 

11.5.2.43 Wait indication 196 

11.5.2.44 Satellite system code 196 

1 1 .5.2.45 CCS configuration parameters 197 

1 1 .5.2.46 Forward epoch delay 198 

1 1 .5.2.47 HPA/HMS Configuration 199 

1 1 .5.2.48 Location area code 200 

11.5.2.49 Beam pair LU timer 201 

1 1 .5.2.50 Paging request reference 201 

11.5.2.51 (Deleted) 202 

1 1 .5.2.52 Satelhte Frequency List 202 

1 1 .5.2.52. 1 Implementation Requirement 203 

11.5.3 Mobility Management information elements 204 

11.5.3.1 Authentication parameter RAND 204 

1 1.5.3.2 Authentication parameter SRES 204 

11.5.3.3 CM service type 205 

11.5.3.4 Identity type 205 

1 1.5.3.5 Location updating type 206 

11.5.3.6 Reject cause 206 

11.5.3.7 Follow-On proceed 207 

1 1 .5.4 Call Control information elements 208 

11.5.4.1 Extensions of codesets 208 

11.5.4.2 Locking shift procedure (Not applicable to current GMR-2 system - specified for future use) 209 

11.5.4.3 Non-locking shift procedure (Not applicable to current GMR-2 system -specified for future use). ...210 

11.5.4.4 Auxihary states 210 

11.5.4.5 Bearer capabihty 211 

1 1 .5.4.5. 1 Static conditions for the bearer capability IE contents 217 

1 1 .5.4.5a Call control capabiUties 218 

11.5.4.6 Call state 218 

1 1 .5.4.7 Called party BCD number 219 

1 1 .5.4.8 Called party subaddress 221 

1 1 .5.4.9 Calling party BCD number 222 

1 1 .5.4. 10 Calling party subaddress 223 

11.5.4.11 Cause 224 

11.5.4.11a CLIR suppression (Not applicable to current GMR-2 system - specified for future use) 229 

1 1.5.4.1 lb CLIR invocation (Not applicable to current GMR-2 system - specified for future use) 229 

1 1.5.4.12 Congestion level (Not applicable to current GMR-2 system - specified for future use) 229 

11.5.4.13 Connected number (Not appUcable to current GMR-2 system - specified for future use) 230 

1 1.5.4.14 Connected subaddress (Not applicable to current GMR-2 system - specified for future use) 230 

11.5.4.15 Facility 231 

11.5.4.16 High layer compatibihty 231 

11.5.4.16.1 Static conditions for the high layer compatibility IE contents 232 

11.5.4.17 Keypad facility 232 

11.5.4.18 Low layer compatibility 232 

1 1 .5.4. 19 More data (Not applicable to current GMR-2 system - specified for future use) 233 

1 1 .5.4.20 Notification indicator (Not appHcable to current GMR-2 system - specified for future use) 233 

1 1 .5.4.21 Progress indicator 233 

1 1 .5.4.22 Repeat indicator 235 

1 1 .5.4.22a Reverse call setup direction 235 

11.5.4.23 Signal 235 

1 1.5.4.24 SS version indicator 236 

1 1 .5.4.25 User-user (Not appUcable to current GMR-2 system - specified for future use) 236 



ETSI 



GMR-2 04.008 



14 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



1 2 List of system parameters 238 

12.1 Timers 238 

12.1.1 Timers on the Mobile Earth Station side 238 

12.1.2 Timers on the Network side 238 

12.1.3 Other parameters 239 

12.2 Timers of Mobility Management 239 

12.2.1 Timer T3240 240 

12.3 Timers of Circuit- Switched Call Control 241 

Annex A (informative): Example of subaddress information element coding 242 

Annex B (normative): Compatibility Checking 243 

B.l Introduction 243 

B.2 Calling Side Compatibility Checking 243 

B.2. 1 Compatibility Checking of the CM SERVICE REQUEST Message 243 

B.2.2 Compatibility Subscription Checking of the SETUP Message 243 

B.3 Called Side Compatibility Checking 244 

B.3.1 Compatibility Checking with Addressing Information 244 

B.3.2 Network-to-MES Compatibility Checking 244 

B. 3.3 User-to-User Compatibility Checking 244 

B .4 High Layer Compatibihty Checking 244 

Annex C (normative): Low layer information coding principles 245 

C. l Purpose 245 

C.2 Principles 245 

C.2. 1 Definition of Types of Information 245 

C.2.2 Examination by Network 245 

C.2.3 Location of Type I Information 246 

C.2.4 Location of Types II and 111 Information 246 

C.2.5 Relationship Between Bearer Capability and Low Layer Compatibility Information Elements 246 

Annex D (informative): Examples of bearer capability information element coding 247 

Annex E (informative): Comparison between call control procedures specified in GMR-2 

04.008 and ITU-T Recommendation Q.931 248 

Annex F (informative): Specific cause values for Radio Resource Management 249 

Annex G (Informative): Specific cause values for Mobility Management 251 

G. 1 Causes Related to Mobile Earth Station Identification 25 1 

G.2 Causes Related to Subscription Options 25 1 

G.3 Causes Related to PLMN Specific Network Failures and Congestion 252 

G.4 Causes Related to Nature of Request 252 

G. 5 Causes Related to Invalid Messages 252 

Annex H (informative): Specific cause values for Call Control 254 

H. l Normal Class 254 

H. 1 . 1 Cause No. 1 "Unassigned (Unallocated) Number" 254 

H. 1 .2 Cause No. 3 "No Route To Destination" 254 

H.1.3 Cause No. 6 "Channel Unacceptable" 254 

H.1.4 Cause No. 8 "Operator Determined Barring" 254 

H. 1 .5 Cause No. 16 "Normal Call Clearing" 254 

H. 1 .6 Cause No. 17 "User Busy" 254 

H.1.7 Cause No. 18 "No User Responding" 254 

H. 1 .8 Cause No. 19 "User Alerting, No Answer" 254 



ETSI 



GMR-2 04.008 



15 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



H. 1 .9 Cause No. 21 "Call Rejected" 255 

H. 1 . 10 Cause No. 22 "Number Changed" 255 

H. 1 . 1 1 Cause No. 26 "Non-Selected User Clearing" 255 

H. 1 . 12 Cause No. 27 "Destination Out Of Order" 255 

H. 1 . 1 3 Cause No. 28 "Invalid Number Format (Incomplete Number)" 255 

H. 1 . 14 Cause No. 29 "Facility Rejected" 255 

H. 1 . 15 Cause No. 30 "Response To STATUS ENQUIRY" 255 

H.1.16 Cause No. 31 "Normal, Unspecified" 255 

H.2 Resource Unavailable Class 255 

H.2. 1 Cause No. 34 "No Circuit/Channel Available" 255 

H.2.2 Cause No. 38 "Network Out of Order" 256 

H.2.3 Cause No. 41 "Temporary Failure" 256 

H.2. 4 Cause No. 42 "Switching Equipment Congestion" 256 

H.2. 5 Cause No. 43 "Access Information Discarded" 256 

H.2.6 Cause No. 44 "Requested Circuit/Channel Not Available" 256 

H.2.7 Cause No. 47 "Resource Unavailable, Unspecified" 256 

H.3 Service or Option Not Available Class 256 

H.3. 1 Cause No. 49 "Quality of Service Unavailable" 256 

H.3.2 Cause No. 50 "Requested Facility Not Subscribed" 256 

H.3. 3 Cause No. 55 "Incoming Calls Barred within the CUG" 256 

H.3.4 Cause No. 57 "Bearer Capability Not Authorized" 257 

H.3.5 Cause No. 58 "Bearer Capability Not Presently Available" 257 

H.3.6 Cause No. 63 "Service or Option Not Available, Unspecified" 257 

H.3.7 Cause No. 68 "ACM Equal To or Greater Than ACMmax" 257 

H.4 Service or Option Not Implemented Class 257 

H.4.1 Cause No. 65 "Bearer Service Not Implemented" 257 

H.4.2 Cause No. 69 "Requested Facility Not Implemented" 257 

H.4.3 Cause No. 70 "Only Restricted Digital Information Bearer CapabiUty Is Available" 257 

H.4.4 Cause No. 79 "Service or Option Not Implemented, Unspecified" 257 

H.5 Invalid Message (e.g., Parameter Out of Range) Class 258 

H.5 . 1 Cause No. 8 1 "hivahd Transaction Identifier Value" 258 

H.5.2 Cause No. 87 "User Not Member of CUG" 258 

H.5. 3 Cause No. 88 "Incompatible Destination" 258 

H.5.4 Cause No. 91 "hivalid Transit Network Selection" 258 

H.5.5 Cause No. 95 "Semantically Incorrect Message 258 

H.6 Protocol Error (e.g., Unknown Message) Class 258 

H.6.1 Cause No. 96 "Invalid Mandatory Information" 258 

H.6. 2 Cause No. 97 "Message Type Non-Existent or Not Implemented" 258 

H.6.3 Cause No. 98 "Message Type Not Compatible With Protocol State" 258 

H.6.4 Cause No. 99 "Information Element Non-Existent or Not Implemented" 259 

H.6.5 Cause No. 100 "Conditional IE Error" 259 

H.6.6 Cause No. 101 "Message Not Compatible With Protocol State" 259 

H.6.7 Cause No. 102 "Recovery On Timer Expiry" 259 

H.6.8 Cause No. 1 1 1 "Protocol Error, Unspecified" 259 

H.7 Interworking Class 259 

H.7. 1 Cause No. 127 "Interworking, Unspecified" 259 

History 260 



ETSI 



GMR-2 04.008 



16 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



Intellectual Property Rights 

The information pertaining to essential IPRs is publicly available for ETSI members and non-members, and can be 
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to 
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server ( http ://www.etsi . org/ipr ) . 

The attention of ETSI has been drawn to the Intellectual Property Rights (IPRs) listed below which are, or may be, or 
may become. Essential to the present document. The IPR owner has undertaken to grant irrevocable licences, on fair, 
reasonable and non-discriminatory terms and conditions under these IPRs pursuant to the ETSI IPR Policy. Further 
details pertaining to these IPRs can be obtained directly from the IPR owner. 

The present IPR information has been submitted to ETSI and pursuant to the ETSI IPR Policy, no investigation, 
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not 
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, 
essential to the present document. 

IPRs: 



Project 


Company 


Title 


Country 
of Origin 


Patent n ° 


Countries 
Applicable 


TS 101 377 


Digital Voice 




US 


US 


US 


VI. 1.1 


Systems Inc 






5,715,365 




TS 101 377 


Digital Voice 




US 


US 


US 


VI. 1.1 


Systems Inc 






5,754,974 




TS 101 377 


Digital Voice 




us 


US 


us 


VI. 1.1 


Systems Inc 






5,226,084 




TS 101 377 


Digital Voice 




us 


US 


us 


VI. 1.1 


Systems Inc 






5,701,390 




TS 101 377 


Digital Voice 




us 


US 


us 


VI. 1.1 


Systems Inc 






5,826,222 





IPR Owner: Digital Voice Systems Inc 

One Van de Graaff Drive Burlington, 

MA 01803 

USA 



Contact: John C. Hardwick 

Tel.: +1 781-270-1030 
Fax: -1-1 781-270-0166 



Project 


Company 


Title 


Country 
of Origin 


Patent n ° 


Countries 
Applicable 


TS 101 377 


Ericsson Mobile 


Improvements in, or in 


GB 


GB2215 


GB 


VI. 1.1 


Communication 


relation to, equalisers 




567 




TS 1 01 377 


Ericsson Mobile 


Power Booster 


GB 


GB2 251 


GB 


VI. 1.1 


Communication 






768 




TS 101 377 


Ericsson Mobile 


Receiver Gain 


GB 


GB 2 233 


GB 


VI. 1.1 


Communication 






846 




TS 101 377 


Ericsson Mobile 


Transmitter Power Control for 


GB 


GB 2 233 


GB 


VI. 1.1 


Communication 


Radio Telephone System 




517 





IPR Owner: Ericsson Mobile Communications (UK) Limited 
The Keytech Centre, Ashwood Way 
Basingstoke 
Hampshire RG23 8BG 
United Kingdom 

Contact: John Watson 

Tel.: -1-44 1256 864821 



£75/ 



GMR-2 04.008 



17 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



Project 


Company 


Title 


Country of 
Origin 


Patent 

n° 


Countries 
Applicable 


TS 101 377 
VI. 1.1 


Hughes Network 
Systems 




US 


Pending 


US 



IPR Owner: Hughes Network Systems 
11717 Exploration Lane 
Germantown, Maryland 20876 
USA 



Contact: John T. Whelan 

Tel: +1 301-428-7172 
Fax: -1-1 301-428-2802 



Project 


Company 


Title 


Country of 
Origin 


Patent n ° 


Countries 
AoDlicable 


TS 101 377 
VI. 1.1 


Lockheed Martin 
Global 

Telecommunic. 
Inc 


2.4-to-3 KBPS Rate 
Adaptation Apparatus for Use 
in Narrowband Data and 
Facsimile Communication 
Systems 


US 


us 

6,108,348 


US 


TS 101 377 
VI. 1.1 


Lockheed Martin 
Global 

Telecommunic. 
Inc 


Cellular Spacecraft TDMA 
Communications System with 
Call Interrupt Coding System 
for Maximizing Traffic 
ThroughputCellular Spacecraft 
TDMA Communications 
System with Call Interrupt 
Coding System for Maximizing 
Traffic Throughput 


US 


US 

5,717,686 


us 


TS 1 01 377 
VI. 1.1 


Lockheed Martin 
Global 

Telecommunic. 
Inc 


Enhanced Access Burst for 
Random Access Channels in 
TDMA Mobile Satellite System 


us 


US 

5,875,182 




TS 101 377 
VI. 1.1 


Lockheed Martin 

Global 

Telecommunic. 
Inc 


Spacecraft Cellular 
Communication System 


us 


US 

5,974,314 


us 


TS 101 377 
VI. 1.1 


Lockheed Martin 
Global 

Telecommunic. 
Inc 


Spacecraft Cellular 
Communication System 


us 


US 

5,974,315 


us 


TS 101 377 
VI. 1.1 


Lockheed Martin 
Global 

Telecommunic. 
Inc 


Spacecraft Cellular 
Communication System with 
Mutual Offset High-argin 
Forward Control Signals 


us 


US 

6,072,985 


us 


TS 101 377 
VI. 1.1 


Lockheed Martin 
Global 

Telecommunic. 
Inc 


Spacecraft Cellular 
Communication System with 
Spot Beam Pairing for 
Reduced Updates 


us 


US 

6,118,998 


us 



IPR Owner: Lockheed Martin Global Telecommunications, Inc. 
900 Forge Road 
Norristown, PA. 19403 
USA 

Contact: R.F. Franciose 

Tel.: -Hi 610.354.2535 
Fax: -1-1 610.354.7244 



ETSI 



GMR-2 04.008 



18 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 

The contents of the present document are subject to continuing work within TC-SES and may change following formal 
TC-SES approval. Should TC-SES modify the contents of the present document it will then be republished by ETSI 
with an identifying change of release date and an increase in version number as follows: 

Version l.m.n 

where: 

• the third digit (n) is incremented when editorial only changes have been incorporated in the specification; 

• the second digit (m) is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc. 

The present document is part 4, sub-part 7 of a multi-part deUverable covering the GEO-Mobile Radio Interface 
Specifications, as identified below: 



Part 1 
Part 2 
Parts 



"General specifications"; 
"Service specifications"; 
"Network specifications"; 



Par 1 4 : " Radio inter face protocol specifications ' ' ; 

Sub-part 1: "GMR-2 Mobile Earth Station-Network Interface; General Aspects and Principles; 
GMR-2 04.001"; 

Sub-part 2: "GMR-2 Mobile Earth Station-Network Interface; Channel Structures and Access capabilities; 
GMR-2 04.003"; 

Sub-part 3: "Layer 1 General requirements; GMR-2 04.004"; 

Sub-part 4: "Data Link Layer General Aspects; GMR-2 04.005"; 

Sub-part 5: "GMR-2 Mobile Earth Station - Network Interface; Data Link (DL) layer Specifications; 
GMR-2 04.006"; 

Sub-part 6: "Mobile Radio Interface Signalling Layer 3; General Aspects; GMR-2 04.007"; 

Sub-part 7: "Mobile radio interface Layer 3 Specifications; GMR-2 04.008" ; 

Sub-part 8: "Point-to-Point Short Message Services; GMR-2 04.01 1 "; 

Sub-part 9: "Performance requirements on the mobile radio interface; GMR-2 04.013"; 

Sub-part 10: "Rate Adaptation on the Mobile Earth Station (MES) - Gateway System Interface; 
GMR-2 04.021"; 

Sub-part 11: "Call Waiting (CW) and Call Holding (HOLD) Supplementary Services; GMR-2 04.083"; 

Sub-part 12: "Multiparty Supplementary Services (MPTY); GMR-2 04.084"; 

Sub-part 13: "Technical Realisation of the Early Flag Technique; GMR-2 04.201"; 

Sub-part 14: "Call Barring Supplementary Services; GMR-2 02.088"; 
Part 5: "Radio interface physical layer specifications"; 
Part 6: "Speech coding specifications". 
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Introduction 

GMR stands for GEO (Geostationary Earth Orbit) Mobile Radio interface, which is used for mobile satellite services 
(MSS) utilizing geostationary satenite(s). GMR is derived from the terrestrial digital cellular standard GSM and 
supports access to GSM core networks. 

Due to the differences between terrestrial and satellite channels, some modifications to the GSM standard are necessary. 
Some GSM specifications are directly applicable, whereas others are applicable with modifications. Similarly, some 
GSM specifications do not apply, while some GMR specifications have no corresponding GSM specification. 

Since GMR is derived from GSM, the organisation of the GMR specifications closely follows that of GSM. The GMR 
numbers have been designed to correspond to the GSM numbering system. All GMR specifications are allocated a 
unique GMR number as follows: 

GMR-n xx.zyy 

where : 

xx.Oyy (z=0) is used for GMR specifications that have a corresponding GSM specification. In this case, the 
numbers xx and yy correspond to the GSM numbering scheme. 

xx.2yy (z=2) is used for GMR specifications that do not correspond to a GSM specification. In this case, only the 
number xx corresponds to the GSM numbering scheme and the number yy is allocated by GMR. 

n denotes the first (n=l) or second (n=2) family of GMR specifications. 

A GMR system is defined by the combination of a family of GMR specifications and GSM specifications as follows: 

• If a GMR specification exists it takes precedence over the corresponding GSM specification (if any). This 
precedence rule appUes to any references in the corresponding GSM specifications. 

NOTE: Any references to GSM specifications within the GMR specifications are not subject to this precedence 
rule. For example, a GMR specification may contain specific references to the corresponding GSM 
specification. 

• If a GMR specification does not exist the corresponding GSM specification may or may not apply. The 
appUcability of the GSM specifications are defined in GMR-n 01.201. 
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1 Scope 

The present document specifies the procedures used at the radio interface (Reference Point Um, see GSM 04.02 [11]) 
for Call Control (CC), Mobility Management (MM) and Radio Resource (RR) management. 

These procedures are defined in terms of messages exchanged over the control channels of the radio interface. The 
control channels are described in GMR-2 04.003 [12]. 

The structured functions and procedures of this protocol and the relationship with other layers and entities are described 
in general terms in GMR-2 04.007 [16]. 

1.1 General 

The procedures currently described in the present document are for the call control of circuit- switched connections, 
mobility management and radio resource management. 

GSM 04.10 [17] contains functional procedures for support of supplementary services. 

NOTE: "Layer 3" includes the functions and protocols described in the present document. 

The terms "Data Link Layer" and "Layer 2" are used interchangeably to refer to the layer immediately 
below Layer 3. 

1 .2 Application to the Interface Structures 

The Layer 3 procedures apply to the interface structures defined in GMR-2 04.003 [12]. They use the functions and 
services provided by Layer 2 defined in GMR-2 04.005 [14] and GMR-2 04.006 [15]. GMR-2 04.007 [16] gives the 
general description of Layer 3 including procedures, messages format and error handling. 

1 .3 Structure of Layer 3 Procedures 

A building block method is used to describe the Layer 3 procedures. 

The basic building blocks are "elementary procedures" provided by the protocol control entities of the three sublayers, 
i.e., Radio Resource Management, Mobility Management and Connection Management sublayers. 

Complete Layer 3 transactions consist of specific sequences of elementary procedures. The term "structured procedure" 
is used for these sequences. 

1 .4 Use of Logical Channels 

The logical control channels are defined in GMR-2 05.002 [23]. In the following those control chaimels are considered 
which carry signalling information or specific types of user packet information: 

a) SatelUte Eighth Rate Standalone Dedicated Control Channel (S-SDCCH/E); 

b) SatelUte Full Rate Fast Associated Control Channel (S-FACCH/F); 

c) Satellite Half Rate Fast Associated Control Channel (S-FACCH/H); 

d) Satellite Quarter Rate Fast Associated Control Channel (S-FACCH/Q); 

e) Satellite Eighth Rate Fast Associated Control Channel (S-FACCH/E); 

f) SatelUte Slow, S-TCH/F Associated Control Channel (S-SACCH/TF); 

g) SatelUte Slow, S-TCH/H Associated Control Channel (S-SACCH/TH); 

h) SatelUte Slow, S-TCH/Q Associated Control Channel (S-SACCH/TQ); 
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i) SatelUte Slow, S-TCH/E Associated Control Channel (S-SACCH/TE); 

j) SatelUte Slow, S-SDCCH/F Associated Control Channel (S-SACCH/CF); 

k) SatelUte Slow, S-SDCCH/H Associated Control Channel (S-SACCH/CH); 

1) SatelUte Slow, S-SDCCH/Q Associated Control Channel (S-SACCH/CQ); 

m) SatelUte Slow, S-SDCCH/E Associated Control Channel (S-SACCH/CE); 

n) SatelUte Broadcast Control Channel (S-BCCH); 

o) SatelUte High Margin Broadcast Control Channel (S-HBCCH); 

p) SatelUte High Margin Synchronization Channel (S-HMSCH); 

q) SatelUte Synchronization Channel (S-SCH); 

r) SatelUte Random Access Channel (S-RACH); 

s) SatelUte Paging Channel (S-PCH) (not implemented at present in GMR-2; 

t) Satellite Access Grant Channel (S-AGCH); 

u) SatelUte High Power Alerting Channel (S-HPACH). 

Two service access points are defined on signalling Layer 2 which are discriminated by their Service Access Point 
Identifiers (SAPI) (see GMR-2 04.006 [15]): 

i) SAP 0: Supports the transfer of signalling information including user-user information; 

ii) SAP 3: Supports the transfer of user short messages. 

Layer 3 selects the service access point, the logical control channel and the mode of operation of Layer 2 
(acknowledged, unacknowledged or random access, see GMR-2 04.005 [14] and GMR-2 04.006 [15]) as required for 
each individual message. 

1 .5 Overview of Control Procedures 
1 .5. 1 List of Procedures 

The following procedures are specified in the present document: 

1) Clause 4 specifies elementary procedures for Radio Resource management: 

a) System information broadcasting (clause 4.2.2); 

b) Radio resources connection establishment (clause 4.3): 

i) Immediate assignment procedure (clause 4.3.1); 

ii) Paging procedure (clause 4.3.2). 

c) Radio resources connection transfer phase (clause 4.4): 

i) Measurement report procedure (clause 4.4. 1 .2); 

ii) Intraspotbeam change of channels (clause 4.4.3); 

iii) Channel mode change procedure (clause 4.4.6); 

iv) Ciphering mode setting procedure (clause 4.4.7). 

d) Radio resources connection release (clause 4.5). 
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2) Clause 5 specifies elementary procedures for Mobility Management: 

a) Mobility management common procedures (clause 5.3); 

i) Authentication procedure (clause 5.3.2); 

ii) Identification procedure (clause 5.3.3). 

b) Mobility management specific procedures (clause 5.4): 

i) Location updating procedure (clause 5.4.1); 

ii) Periodic updating (clause 5.4.2); 

iii) Generic location updating procedure (clause 5.4.4). 

c) Coimection management sublayer service provision: 

i) Mobility management cormection establishment (clause 5.5.1); 

ii) Mobility management connection information transfer phase (clause 5.5.2); 

iii) Mobility management connection release (clause 5.5.3). 

3) Clause 6 specifies elementary procedures for circuit switched Call Control comprising the following elementary 
procedures: 

a) Mobile originating call establishment (clause 6.2.1); 

b) Mobile terminating call establishment (clause 6.2.2); 

c) Signalling procedures during the active state (clause 6.3): 
i) DTMF protocol control procedure (clause 6.3.3); 

d) Call clearing initiated by the MES (clause 6.4.3); 

e) Call clearing initiated by the network (clause 6.4.4); 

f) Miscellaneous procedures: 

i) In-band tones and announcements (clause 6.5. 1); 

ii) Status enquiry procedures (clause 6.5.3). 

The elementary procedures can be combined to form structured procedures. Examples of such structured procedures are 
given in clause 8. This part of the Technical Specification is only provided for guidance to assist implementations. 

Clause 9 specifies actions to be taken on various error conditions. 
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3 Definitions and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Idle mode: in this mode, the MES is not allocated any dedicated channel; it listens to the S-HPACH, the S-BCCH 
and/or S-HBCCH 

Main S-DCCH: in RR connected mode, only two channels are used as S-DCCH, one being a S-SACCH, the other 
being a S-SDCCH or a S-FACCH; the S-SDCCH or S-FACCH is called here "The main S-DCCH": 

a channel is activated if it can be used for transmission, in particular for signalling, at least with UI frames. On 
the S-SACCH, whenever activated, it must be ensured that a contiguous stream of Layer 2 frames is sent; 

- a S-TCH is connected if circuit mode user data can be ttansferred. A S-TCH cannot be connected if it is not 
activated. A S-TCH which is activated but not connected is used only for signalling, i.e., as a S-DCCH; 

- the Data Link of SAPI on the main S-DCCH is called the main signalling link. Any message specified to be 
sent on the main signalling link is sent in acknowledged mode except when otherwise specified; 

- the term "to establish" a link is a short form for "to establish the multiframe mode" on that Data Link. It is 

possible to send UI frames on a Data Link even if it is not established as soon as the corresponding channel is 
activated. Except when otherwise indicated, a Data Link layer establishment is done without an information field 

Random values: in a number of places in the present document, it is mentioned that some value must take a "random" 
value in a given range, or more generally, with some statistical distribution. Such cases interest only the Mobile Earth 
Station (MES): 

- it is required that there is a low probability that two MESs in the same conditions (including the case of two 
MESs of the same type from the same manufacturer) will choose the same value. Moreover, it is required that, if 
it happens that two MESs in similar conditions choose the same value, the probability of their choices being 
identical at the next occasion is the same as if their first choices had been different; 
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the meaning of such a specification is that any statistical test for these values, done on a series of similar events, 
will obtain a result statistically compatible with the specified distribution. This shall hold even in the cases where 
the tests are conducted with a subset of possible events, with some coimnon parameters. Moreover, basic tests of 
independence of the values within the series shall pass; 

data against which correlation with the values shall not be found are the protocol state, or the IMSI, or identities 
or other unrelated information broadcast by the network, or the current TDMA frame number 

RR connected mode: in this mode, the MES is allocated at least two dedicated channels, only one of them being a S- 
SACCH 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 
ARFCN Absolute Radio Frequency Channel Number 

Other abbreviations used in the present document are listed in GMR-2 01.004 [1]. 



4 Radio resource management procedures 

4.1 Overview 

4.1.1 General 

Radio Resource management procedures include the functions related to the management of the common transmission 
resources, e.g., the physical channels and the Data Link connections on control channels. 

The general purpose of Radio Resource procedures is to establish, maintain and release RR connections that allow a 
point-to-point dialogue between the network and a MES. This includes the spotbeam selection/reselection. Moreover, 
Radio Resource management procedures include the reception of the uni-directional S-BCCH and S-CCCH when no 
RR connection is established. This permits automatic spotbeam selection/reselection. 

4.1 .2 Services provided to upper layers 

4.1.2.1 Idle mode 

The RR procedures include (on the Mobile Earth Station side) those for automatic spotbeam selection/reselection. The 
RR entity indicates to upper layers the unavailability of a S-BCCH/S-CCCH and the spotbeam change when decided by 
the RR entity. Upper layers are advised of the S-BCCH broadcast information when a new spotbeam has been selected, 
or when a relevant part of this information changes. 

4.1 .2.2 Establishment and release of a RR connection 

A RR coimection is a physical point-to-point bi-directional connection, and includes a SAPI Data Link coimection 
operating in multiframe mode on the main S-DCCH. 

The upper layer can require the establishment of a RR connection. Only one RR connection can be established for a 
MES at one time. 

The upper layer can require the release of a RR connection. 
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4.1 .2.3 RR connected mode 

When a RR connection is established, RR procedures provide the following services: 

a) establishment/release of multiframe mode on Data Link layer connections other than SAPI 0, on the main S- 
DCCH or on the S-SACCH; 

b) transfer of messages on any Data Link layer connection; 

c) indication of temporary unavaUabiUty of transmission (suspension, resuming); 

d) indication of loss of RR connection; 

e) setting/change of the transmission mode on the physical channels, including change of type of channel, change 
of the coding/decoding/transcoding mode and setting of ciphering; 

f) allocation/release of additional channels (for S-TCH half, quarter or eighth rate configuration). 

4.1 .3 Services required from data link and physical layers 

The RR sublayer uses the services provided by the Data Link layer as defined in Technical Specification 
GMR-2 04.005 [14]. 

Moreover, the RR sublayer directly uses services provided by the physical layer such as S-BCCH searching, as defined 
in Technical Specification GMR-2 04.004 [13]. 

4.1 .4 Change of dedicated channels 

4.1 .4.1 Change of dedicated channels using SAPI = 

In case a change of dedicated channels is required using a dedicated assignment procedure, the RR sublayer will request 
the Data Link layer to suspend multiple frame operation before the MES leaves the old channel. When the channel 
change has been completed. Layer 3 vnll request the Data Link layer to resume multiple frame operation again. The 
Layer 2 suspend/resume procedures are described in GMR-2 04.005 [14] and GMR-2 04.006 [15]. 

These procedures are specified in such a way that a loss of a Layer 3 message cannot occur on the radio interface. 
However, MM and CM messages sent from the MES to the network may be duplicated by the Data Link layer if a 
message has been ttansmitted but not yet completely acknowledged before the MES leaves the old channel (see 
GMR-2 04.006 [15]). 

As the RR sublayer is controlling the chaimel change, a duplication of RR messages does not occur. However, there are 
some procedures for which a duphcation is possible, e.g., DTMF procedures. For all MM and CM procedures using 
SAPI = 0, the request messages sent by the MES contain a sequence number in order to allow the network to detect 
duplicated messages, which are then ignored by the network. The procedures for sequenced ttansmission on Layer 3 are 
described in clause 4.1.4.3. 

4.1 .4.2 Change of dedicated channels using other SAPIs than 

For SAPIs other than 0, the Data Link procedures described in GMR-2 04.006 [15] do not provide any guarantee 
against message loss or duplication. 

Therefore, if an application uses a SAPI other than 0, and if this appUcation is sensitive to message loss or duphcation, 
then it has to define its own protection mechanism. No general protection mechanism is provided by the Layer 3 
defined in the present document. 

NOTE: Support of special mechanisms against the loss or duplication of messages is not a requirement of the 
MSC. 
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4.1 .4.3 Sequenced Message Transfer Operation 

MM and CM messages using SAPI = sent from the MES to the network can be dupUcated by the Data Link layer in 
the following case: 

A channel change of dedicated channels is required (assignment procedure) and the last Layer 2 frame has not been 
acknowledged by the peer Data Link layer before the MES leaves the old channel. 

In this case, the MES does not know whether the network has received the message correctly. Therefore, the MES has 
to send the message again after the new dedicated channel is established (see GMR-2 04.006 [15]). 

The network must be able to detect the duplicated received message. Therefore, each MM and CM message using SAPI 
= must be marked with a send sequence number. 

4.1 .4.3.1 Variables and Sequence Numbers 

4.1.4.3.1.1 Send State Variable V(SD) 

The RR sublayer of the MES shall have one associated send state variable V(SD) ("Send DupUcated") for sending MM 
and CM messages using SAPI =0. The send state variable denotes the sequence number of the next in sequence 
nimibered message to be transmitted. The value of the send state variable shall be incremented by one with each 
numbered message transmission. Arithmetic operations on V(SD) are performed modulo 2. 

4.1 .4.3.1 .2 Send Sequence Number N(SD) 

Only MM and CM messages using SAPI = contain the send sequence number N(SD). At the time when such a 
message is designated for transmission, the value of N(SD) for the message to be transferred is set equal to the value of 
the send state variable V(SD) (see GMR-2 04.007 [16]). 

4.1 .4.3.2 Procedures for the initiation, transfer execution and termination of tfie sequenced 
message transfer operation 

4.1.4.3.2.1 Initiation 

The sequenced message transfer operation is initiated by establishing a RR connection. The send state variable V(SD) is 
set to 0. 

4. 1.4.3.2.2 Transfer Execution 

The network must compare the send sequence numbers of pairs of subsequent messages. In case the send sequence 
numbers of two subsequent messages are not identical, no duplication has occurred. In case the send sequence numbers 
are identical, the network must ignore one of these messages. 

4.1.4.3.2.3 Termination 

The sequenced message transfer operation is terminated by the RR connection release procedure. 
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4.1 .5 Procedure for Service Request and Contention Resolution 

upon seizure of the assigned dedicated channel, the MES establishes the main signalUng link on this channel by 
sending a Layer 2 SABM frame containing a Layer 3 service request message. The Data Link layer will store this 
message to perform the contention resolution. The service request message will be returned by the network in the UA 
frame. 

The Data Link layer in the MES compares the content of the information field (i.e., the Layer 3 service request 
message) received in the UA frame with the stored message and leaves the channel in case they do not match. This 
procedure resolves contentions in the case where several MESs have accessed at the same random access slot and with 
the same random reference and one has succeeded due to capture. The full description of the procedure is given in 
GMR-2 04.006 [15]. 

The purpose of the service request message is to indicate to the network which service the MES is requesting. This then 
allows the network to decide how to proceed (e.g., to authenticate or not). 

The service request message must contain the identity of the MES and may include further information which can be 
sent without encryption. 

The Layer 3 service request message is typically one of the following: 

a) CM SERVICE REQUEST 

b) LOCATION UPDATING REQUEST 

c) PAGING RESPONSE 



Mobile Earth Station Network 
SABM ("Layer 3 service request message") 



UA ("Layer 3 service request message") 



Figure 4.1 : Service request and contention resolution 

4.2 Idle mode procedures 
4.2.1 IVIES side 

In idle mode, the MES listens to the S-BCCH and to the paging sub-channel for the paging group the MES belongs to 
and measures the radio propagation for coimection with other spotbeams. 

Measurements are used to assess the need of a spotbeam change as specified in Technical Specification 
GMR-2 05.008 [26]. When the decision to change spotbeams is made, the MES switches to the S-BCCH of the new 
beam. The broadcast information is then checked to verify the allowance to camp on this beam (see clause 4.2.2). If 
allowed, the spotbeam change is confirmed, and the broadcast information is then treated for Mobility Management 
actions (see clause 5). Similarly, physical contexts are updated (list of neighboring spotbeam frequencies, thresholds for 
some actions, etc., see Techrucal Specification GMR-2 05.008 [26] and clause 4.2.2 of the present document). 
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4.2.2 



Network Side 



4.2.2.1 



System Information Broadcasting 



The Satellite Broadcast Control Channel (S-BCCH) and the Satellite High Margin Broadcast Control Channel (S- 
HBCCH) are the logical channels used to broadcast system information messages from the network to the MES. System 
information messages provide information about the network as well as spotbeam specific information. 

The GMR-2 system uses the following system information messages: Type 2, Type 3, Type 9, Type 10, Type 8 and 



A Type 2 message contains information on surrounding neighbor spotbeams (LARFCN, CO, FSG and FO) and access 
control parameters. See clause 10.1.32. 

A Type 3 message contains information on the current spotbeam LAI, control channel description, spotbeam options, 
spotbeam selection and reselection parameters and access control parameters. See clause 10.1.34. 

A Type 9 message contains information on common control channel configuration, forward epoch delay, HPA/HMS 
configuration and access control parameters. See clause 10.1.41. 

A Type 10 message contains the current spotbeam Location Area Code (LAC), surrounding neighbor beam pair LACs, 
Beam Pair Location update timer setting and access control parameters. See clause 10.1.42. 

Type 8 messages are used to create an active frequency list. The active frequency list provides the common control 
channel frequencies for all 140 spotbeams. Each Type 8 message can list 20 frequencies. Therefore, seven Type 8 
messages are required to create the complete active frequency list. See clause 10.1.40. 

Type 8 messages are also used to create a pending frequency list. The pending frequency list is used when the network 
changes control channel frequencies for spotbeams. The Ust provides the spotbeam number and the new common 
control channel frequency. Each Type 8 message can change up to ten spotbeam frequencies. Therefore, fourteen Type 
8 messages are required to change every frequency in a 140 spotbeam system. See clause 10.1.40. 

The MES determines whether a particular Type 8 message is part of an active or pending frequency list by the value of 
the "Frequency List Type" in the SatelUte Frequency List IE clause 11.5.2.52. 

A Type 7 message is used to create a multi-satelUte frequency list. A multi- satellite frequency list can specify up to 
seven frequencies of a neighboring satellite. The satelUte visibility field in the Channel Request message allows 
reporting a maximum of two satellites. Therefore, there may be up to two Type 7 messages or two multi- satellite 
frequency lists. See clause 10.1.39. 

The S-BCCH and S-HBCCH occupy frames on the common control channel of each spotbeam as shown in 
GMR-2 05.002 [23], figure 9.0.2a and specified in GMR-2 05.002 [23], Table 7.0.5a. 

The same system information messages shall always be broadcast on the S-BCCH and the S-HBCCH. Type 8 System 
Information messages shall always be broadcast on the S-HBCCH. If the S-BCCHext is active, then the same Type 8 
messages shall be broadcast on the S-BCCHext as on the S-HBCCH. If any Type 7 System Information messages are 
active, then the same Type 7 messages shall be broadcast on the S-BCCHext as on the S-HBCCH. The repeat length of 
the S-BCCH is one control multiframe (102 TDMA frames) and therefore system information messages are broadcast 
rapidly on the S-BCCH. Listening to the S-BCCH is the fastest way for the MES to obtain system information 
messages. However, bursts sent over the S-BCCH are transmitted at nominal power level and thus the MES must be in 
advantaged mode to receive these bursts and successfully decode them 

The repeat length of the S-HBCCH is 27 control multiframes. Therefore the broadcast of system information messages 
on the S-HBCCH is much slower than on the S-BCCH. However, bursts on the S-HBCCH are transmitted at a higher 
power level than the S-BCCH so that MESs in disadvantaged mode can receive and successfiilly decode system 
information messages. 

The Type 2, 3, 9 and 10 messages contain the information MESs need to determine how to make and receive calls and 
are therefore the most important to the MES. As a result, system information messages Type 2, 3, 9 and 10 are always 
broadcast on S-BCCH and the S-HBCCH. The Type 7 and 8 system information message contain frequency 
information that MESs do not always need. Therefore system information messages Type 7 and 8 are not always 
broadcast on the S-BCCH. However, Type 8 messages are always broadcast on the S-HBCCH and Type 7 messages 
may be broadcast if a multi-sateUite frequency list(s) exists. 



Type 7. 
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4.2.2.1.1 



Broadcast of System Information Messages on the S-BCCH 



The S-BCCH is divided into two parts: the S-BCCHnorm and the S-BCCHext. 

The S-BCCHnorm is always active and is used to transmit Type 2, 3, 9, and 10 messages. The S-BCCHnorm occupies 
the two blocks on the common control channel TN_0 as specified in GMR-2 05.002 [23], Table 9.0.5a. Since, the repeat 
cycle of the S-BCCHnorm is one control multiframe (102 TDMA frames) and the same message is transmitted in each 
of the two blocks occupied by the S-BCCHnorm, it takes one control multiframe to transmit one System Information 
message. 

The S-BCCHext is used to transmit the Type 7 and/or 8 messages. The use of the S-BCCHext is configurable on a 
spotbeam basis by the NCC operator. The SB-BCCHext-Res parameter (clause 11.5.2.3) is used to configure the use of 
the S-BCCHext and to indicate to the MES how the S-BCCHext is configured. The possibilities are: 

• S-BCCHext not in use; 

• S-BCCHext in use with Type 7 messages only; 

• S-BCCHext in use with Type 8 messages only; 

• S-BCCHext in use with Type 7 and 8 messages. 

When in use, the S-BCCHext occupies the two blocks specified in GMR-2 05.002 [23], Table 9.0.5a. Since, the repeat 
cycle of the S-BCCHext is one control multiframe (102 TDMA frames) and the same message is ttansmitted in each of 
the two blocks occupied by the S-BCCHext, it takes one conttol multiframe to ttansmit one System Information 
message. 

GMR-2 05.002 [23], Table 8.3.1 specifies the order in which system information messages are sent on the 
S-BCCHnorm. That order is Type 2, 3, 9 and 10 System Information messages. It takes four control multiframes to 
fransmit the set of Type 2, 3, 9 and 10 messages. 

GMR-2 05.002 [23], Table 8.3.1 specifies the order in which system information messages Type 8 and Type 7 can be 
sent on the S-BCCHext. That order is seven Type 8 messages and one Type 7 message. If Type 7 messages are not 
used, then nothing shall be ttansmitted in the Type 7 slot on the S-BCCHext. 

When the S-BCCHext is used, as a minimum, the NCC shall transmit the Active Frequency list on the S-BCCHext. If 
the Multi- Satellite Frequency lists are active, then a list shall be transmitted in the cycle. If a pending hst exists, then the 
pending list shall replace the Active list in the eight-conttol frame cycle. 



For system information messages sent on the S-HBCCH, the network uses the H-BCCH Version Number message (see 
clause 10.1.48) to indicate to the MES which message type is to follow. That is, for system information messages sent 
on the S-HBCCH, the MES shall have the ability to distinguish the message type at the message block level. The H- 
BCCH Version Number message indicates to the MES the system information message type (using the "SIM type" 
parameter) and a version number ("Sequence Number" parameter) associated with the System Information Message. 
The H-BCCH Version Number message of 10 bits and the System Information Message of 184 bits are encoded as one 
ttansmitted message on the S-HBCCH logical channel. For details see GMR-2 05.003 [24]. 

The H-BCCH Version Number Message allows the MES to skip decoding the attached System Information Message if 
the sequence number in the Version Number Message is the same as what the MES had decoded before. 

The NCC shall maintain a unique sequence number in the H-BCCH Version Number message for each of the following 
categories of System Information Messages: 

1) Type 2 (a version number for each spotbeam); 

2) Type 3 (a version number for each spotbeam); 

3) Type 9 (a version number for each spotbeam); 

4) Type 10 (a version number for each spotbeam); 

5) Active Frequency List: seven Type 8 messages (one version number for all seven Type 8 messages); 



4.2.2.1.2 



Broadcast of System Information Messages on the S-HBCCH 
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6) Pending Frequency List: up to fourteen Type 8 messages (one version number for all 14 Type 8 messages); 

7) Multi-satellite Frequency Lists: one Type 7 message per satellite, up to two satellites per any geographical area 
(a version number for each Type 7 message). 

The NCC shall choose the appropriate value for the "SIM type" parameter in the H-BCCH Version Number message 
(see clause 10.1.44) to identify the subsequent System Information Message type. The NCC shall increment the 
sequence number in the H-BCCH Version Number message to indicate changes to the System Information message 
content. 

The NCC shall broadcast System Information messages in blocks of six S-HBCCH repeat cycles or six message blocks 
on the S-HBCCH as follows: 



1) 


Type 2; 




2) 


Type 3; 




3) 


Type 9; 




4) 


Type 10; 




5) 


Type 7 or Type i 


I depending on the Ust; 


6) 


Type 7 or Type I 


i depending on the Ust. 



where the S-HBCCH repeat cycle or message block is 27 control multiframes long (2754 TDMA frames). 

TYPE 2, 3, 9 and 10 messages are transmitted on the first four S-HBCCH repeat cycles, since these system information 
messages contain the most important information. 

The fifth and sixth message blocks shall be used to transmit the active, pending and/or mutU- satellite frequecy lists. As 
a minimum the NCC shall send the active frequency list, seven Type 8 messages. If the Multi- Satellite Frequency list(s) 
is active, then a list(s) shall be transmitted in the cycle. If there is no Multi-Satellite Frequency List or it is inactive (i.e., 
no Type 7 System Information messages to send), the NCC shall always send Type 8 messages on the fifth and sixth 
message blocks on the S-HBCCH. If a pending list exists, then the pending list shall replace the Active list. Table 4.2.1 
indicates the amount of time it takes to transmit various combinations of active, multi- satellite and/or pending frequency 
lists on the S-HBCCH. 



Table 4.2.1 : System information message cycle times on the S-HBCCH 



Number of system 
information messages 


Cycle time (min) 


Comment 


7 


4.4 


One Active List 


9 


5.8 


One Active list and 2 Multi-sat lists 


14 


8.8 


One Active list and 7 Pending lists 


16 


10.2 


One Active list , 7 Pending lists, and 2 
Multi-sat lists or 14 Pending lists and 
2 Multi-sat lists 


23 


14.6 


Active list, 14 Pending lists,and 2 
Multi-sat lists 



For example, a sequence of system information messages including one active frequency list (seven Type 8 messages) 
and one multi-satellite list (one Type 7) takes four sets of six S-HBCCH cycles and is ordered as follows. 

On the first set of six S-HBCCH cycles, the system information messages are sent as follows: 

1) Type 2; 

2) Type 3; 

3) Type 9; 

4) Type 10; 
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5) first Type 8; 

6) second Type 8. 

On the second set of six S-HBCCH cycles, the System Information messages are sent in the following order: 



1) 


Type 2; 


2) 


Type 3; 


3) 


Type 9; 


4) 


Type 10; 


5) 


third Type 8 


6) 


fourth Type 



On the third set of six S-HBCCH cycles, the System Information messages are sent in the following order: 

1) Type 2; 

2) Type 3; 

3) Type 9; 

4) Type 10; 

5) Fifth Type 8; 

6) Sixth Type 8. 

On the fourth set of six S-HBCCH cycles, the System Information messages are sent in the following order: 



1) 


Type 2; 


2) 


Type 3; 


3) 


Type 9; 


4) 


Type 10; 


5) 


seventh Type 


6) 


Type?. 



NOTE: In this example, if there are no Type 7 messages to send then Type 8 messages shall be sent on the S- 

HBCCH. Note that, the S-HBCCH broadcast is asynchronous with respect to the Hyperframe cycle of the 
control chaimel multiframe. 

4.2.2.2 Paging 

The network is only required to send a valid Layer 3 message on a paging sub-channel, when there is a page request 
required. 
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4.3 RR connection establishment 

4.3.1 RR connection establishment initiated by tlie MES: Immediate 
assignment procedure 



The purpose of the immediate assignment procedure is to establish an RR connection between the MES and the 

network. 

The immediate assigimient procedure can only be initiated by the RR entity of the MES. Initiation is triggered by 
request from the MM sublayer to establish an RR connection or by the RR entity in response to a PAGING REQUEST 
message. Upon such a request: 

a) if access to the network is allowed (as defined in clause 4.3.1.1), the RR entity of the MES initiates the immediate 
assignment procedure as defined in clause 4.3.1.2; 

b) otherwise, it rejects the request. 

The request from the MM sublayer to establish an RR connection specifies an establishment cause. Similarly, the 
request from the RR entity to establish a RR connection in response to a PAGING REQUEST Type 1 message specifies 
one of the establishment causes "answer to paging." 



All Mobile Earth Stations with an inserted SIM are members of one out of ten access classes numbered to 9. The 
access class niunber is stored in the SIM. In addition, MESs may be members of one or more out of 3 special access 
classes (access classes 13 to 15), this is also held on the SIM card. 

The system information messages on the S-BCCH broadcast the list of authorized access classes and authorized special 
access classes in the system information messages, and whether emergency calls are allowed in the spotbeam to all 
MESs or only to the members of authorized special access classes. 

If the establishment cause for the request of the MM sublayer is not "emergency call," access to the network is allowed 
if and only if the MES is a member of at least one authorized: 

a) access class; or 

b) special access class. 

If the establishment cause for the request of the MM sublayer is "emergency call," access to the network is allowed if 
and only if: 

a) emergency calls are allowed to all MESs in the spotbeam; or 

b) the MES is a member of at least one authorized special access class. 



The RR entity of the MES initiates the immediate assignment procedure by scheduling the sending on the S-RACH and 
leaving idle mode (in particular, the MES shall ignore PAGING REQUEST messages). It then sends maximally M + 1 
CHANNEL REQUEST messages on the S-RACH in a way such that: 

a) the number of S-RACH slots belonging to the MESs S-RACH between initiation of the immediate assignment 
procedure and the first CHANNEL REQUEST message (excluding the slot containing the message itself) is a 
random value drawn randomly for each new initial assignment initiation with uniform probability distribution in 
the set {0, 1...., max (T,8) - 1}; 

b) the number of S-RACH slots belonging to the MES's S-RACH between two successive CHANNEL REQUEST 
messages (excluding the slots containing the messages themselves) is a random value drawn randomly for each 
new transmission with uniform probability distribution in the set {S, S -H l....,S +T - 1 }; 

Here, T is the value of the parameter "Tx-integer" (the number of S-RACH slots over which transmission is spread as 
defined in clause 11.5.2.29) broadcast on the S-BCCH.M is the value of the parameter "max rettans" broadcast on the 



4.3.1.1 



Permission to Access tine Network 



4.3.1.2 



Initiation of the Immediate Assignment Procedure 



S-BCCH. 
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S is a parameter depending on the S-CCCH configuration and on the value of Tx-integer as defined in Table 4.3.1. The 
values of S specified in Table 4.3. 1 are given in terms of S-RACH slot as a function of Tx-integer and the number of 
frames per S-RACH slot. The number of frames per S-RACH slot is specified by the S-RACH configuration parameter 
of the CCS configuration parameter (clause 11.5.2.45) broadcast within Type 9 System Information message for each 
spot beam. 

After sending the first CHANNEL REQUEST message, the MES shall start hstening to the S-BCCH; it shall also hsten 

to the S-AGCH on the proper forward TN. The forward TN is determined by using the HPA_Group 

(GMR-2 05.002 [23] ), finding the TN that the MES monitors for the S-HPACH and choosing the TN in 

GMR-2 05.002 [23], Table 5.3.4 in the "S-CCCH Forward TN" column that appears in the same row as the S-HPACH 

TN in the "S-HPACH Forward TN column" in GMR-2 05.002 [23], Table 5.3-4. 

If the User Terminal has not received a response from the network on the S-AGCH and has sent M -i- 1 CHANNEL 
REQUEST messages, the RR entity of the MES starts timer T3126. At expiration of timer T3126, the immediate 
assignment procedure is aborted; if the immediate assignment procedure was triggered by a request from the MM 
sublayer, a random access failure is indicated to the MM sublayer. 



Table 4.3.1 : Values of parameter S 



TX-lnteger 


Parameter S in S-RACH slots 
(S-RACH Slot Length in frame periods) 


Minimum Time (sec) 


(2) 


(3) 


(4) 


(5) 


(6) 


(7) 


(8) 


(9) 


3,8,14,50 


162 


108 


81 


65 


54 


47 


41 


36 


1.50 


4,9,16 


216 


144 


108 


87 


72 


62 


54 


48 


2.00 


5,10,20 


270 


180 


135 


108 


90 


78 


68 


60 


2.50 


6,11,25 


324 


216 


162 


130 


108 


93 


81 


72 


3.00 


7,12,32 


378 


252 


189 


152 


126 


108 


95 


84 


3.50 



4.3.1 .3 Answer from the network 

4.3.1 .3.1 Receipt of a CHANNEL REQUEST message 

The network may allocate a dedicated channel to the MES by sending an IMMEDIATE ASSIGNMENT message in 
unacknowledged mode on the S-AGCH on the TN group as defined in GMR-2 05.002 [23], Table 5.3.4. The 
IMMEDIATE ASSIGNMENT message may be sent in any S-AGCH block on the TN group. The type of channel 
allocated is S-SDCCH. Tinier T3101 is then started on the network side. 

NOTE: There is only one type of immediate assignment message used that contains assignment information for 
one MES only. 

The IMMEDIATE ASSIGNMENT message contains: 

a) The description of the assigned channel; 

b) The information field of the CHANNEL REQUEST message and the frame number of the frame in which the 
CHANNEL REQUEST message was received; 

c) The initial timing advance. 

On receipt of an IMMEDIATE ASSIGNMENT message corresponding to one of its 3 last CHANNEL REQUEST 
messages, the MES stops T3126 (if running), stops sending CHANNEL REQUEST messages, switches to the assigned 
channels, sets the channel mode to signalling only and activates the assigned chaimels. It then establishes the main 
signalling link with an SABM containing an information field (see clause 4.1.5). 
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4.3.1.3.2 Assignment rejection 

If no channel is available for assignment, the network may send to the MES an IMMEDIATE ASSIGNMENT REJECT 
message in unacknowledged mode on the S-AGCH on the TN group as defined in GMR-2 05.002 [23], Table 5.3.4. 
The IMMEDIATE ASSIGNMENT REJECT message may be sent in any S-AGCH block on the TN group. This 
message contains the request reference and a wait indication. 

On receipt of an IMMEDIATE ASSIGNMENT REJECT message corresponding to one of its 3 last CHANNEL 
REQUEST messages, the MES stops sending CHANNEL REQUEST messages, starts timer T3122 with the indicated 
value, ("wait indication" information element), starts T3126 if it has not already been started, and Ustens to the forward 
S-CCCH until T3126 expires. During this time, additional IMMEDIATE ASSIGNMENT REJECT messages are 
ignored, but any immediate assignment corresponding to any other of its 3 last CHANNEL REQUEST messages make 
the MES follow the procedure in clause 4.3.1.2. If no such immediate assignment is received, the MES returns to idle 
mode (listening to its paging channel). The MES is not allowed to make a new attempt to establish a non-emergency RR 
connection in the same spotbeam until T3122 expires. Provided that an IMMEDIATE ASSIGNMENT REJECT 
message has not been received for an emergency RR connection attempt, the MES may attempt to establish an RR 
connection for an emergency call in the same spotbeam before T3122 has expired. 

The Wait Indication IE (i.e., T3122) relates to the spotbeam from which it was received. 

After T3122 expiration, no CHANNEL REQUEST message shall be sent as a response to a page until a PAGING 
REQUEST message for the MES is received. 

4.3.1.4 Assignment completion 

The immediate assignment procedure is terminated on the network side when the main signalling link is established. 
Timer T3101 is stopped and the MM sublayer on the network side is informed that an RR connection exists. On the 
MES side, the procedure is terminated when the establishment of the main signalling link is confirmed. The MM 
sublayer is informed that an RR connection exists. 

4.3.1.5 Abnormal Cases 

If a lower layer failure occurs on the MES side on the new channel before the successful establishment of the main 
signalling link, the allocated channels are released; the subsequent behavior of the MES depends on the type of failure 

and previous actions: 

a) If the failure is due to information field mismatch in the contention resolution procedure, see clause 4. 1 .5, and no 
repetition as described in this clause has been performed, the immediate assigimient procedure shall be repeated; 

b) If the failure is due to any other reason or if a repetition triggered by a contention resolution failure has been 
performed. The MES returns to idle mode (RR connection establishment failure), transactions in progress are 
aborted and spotbeam reselection then may take place. 

If the information available in the MES, after the reception of an IMMEDIATE ASSIGNMENT message does not 
satisfactorily define a channel, an RR connection establishment failure has occurred. 

On the network side, if timer T3101 elapses before the main signalling link is established, the newly allocated channels 
are released and the request is forgotten. Note that the network has no means to distinguish repeated attempts from 
initial attempts from a MES. 

4.3.2 Paging procedure 

The network can initiate the estabhshment of an RR connection by the paging procedure. Such a procedure can only be 
initiated by the network. See figure 4.3.2. 

4.3.2.1 Paging initiation by the network 

MESs are assigned to either the S-HPACH or S-PCH paging channels. Fixed MESs which can become mobile or 
handheld are assigned to the S-HPACH. Fixed terminals which can never become mobile or handheld are assigned to 
the S-PCH. Hence, the S-PCH is reserved for paging of a fixed MES in a point-to-point network. Since such a network 
is a future appUcation of the S-PCH, the network and the MES are not required to implement the S-PCH functionaUty. 
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There are only two type of paging message available: 

- PAGING REQUEST - HPACH IMSI, on the S-HPACH 

- PAGING REQUEST - Type 1 on the S-PCH 

4.3.2.1 .1 S-HPACH logical channel use 

The network initiates the paging procedure by broadcasting a paging request message on the appropriate paging 
subchannel, and starts timer T3113. The paging subchannel is specified in GMR-2 05.002 [23]. 

The MES is required to receive and analyze the paging messages sent on the paging subchannel corresponding to its 
paging subgroup, as specified in GMR-2 05.002 [23]. 

MESs assigned to the S-HPACH shall have the capabihty to decode and ignore the PAGING REQUEST - Type 1 
messages when present on the S-PCH as specified in GMR-2 05.002 [23]. 

MESs assigned to the S-HPACH shall ignore the Page Mode IE, clause 11.5.2.26 in the Immediate Assignment, clause 
10.1.18 and in the Immediate Assignment Reject, clause 10.1.20. 

4.3.2.1 .2 S-PCH logical channel use 

[Reserved] 

4.3.2.1 .3 Paging process 

The paging process is used by the network to notify MESs of incoming calls. The gateway MSC initiates the paging 
procedure by sending a paging message to the GSC. The GSC passes the message to the NCC and the NCC sends a 
paging message (PAGING REQUEST message) to the MES. When the MES receives the page fi-om the NCC, what 
happens next depends on whether the MES is in advantaged or disadvantaged mode. If the MES is in advantaged mode, 
then the MES may respond immediately by initiating the immediate assignment procedure. If the MES is in 
disadvantaged mode, then the user must get the MES in advantaged mode (for example, by extending the anteima 
and/or going outside). Once the transition to advantaged mode is successful, the MES can initiate the immediate 
assignment procedure and call set up may proceed. 

The gateway MSC shall initiate a page sequence in the NCC by sending a page request message to the GSC. The GSC 
shall then pass this message to the NCC. The gateway MSC shall use two timers, TPAG and Thpa, to control its part of 
the paging process. The NCC shall be capable of transmitting a unique paging sequence in every spotbeam in the 
system. A paging sequence shall consist of 5 or less separate page attempts transmitted from the NCC to an MES. The 
number of page attempts shall be NCC configurable. 

The amount of time between each page attempt from the NCC shall be configurable by the network operator. To 
facilitate this, the NCC shall use five T31 13 timers, each timer associated with a page attempt. 

The NCC shall transmit each page attempt with a distinct pre-configured power level. 

The NCC shall provide the capabihty for the Network Operator to reduce the power level of each page attempt in the 
paging sequence during periods of high satelUte usage. 
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The NCC shall have the capability to provide an overload indication to other elements in the ground network.The 
parameter HPA Timer represents the amount of time the user has to respond to a page request. The NCC shall transmit 
the value of HPA on the S-BCCH using the HPA/HMS lEI, clause 1 1 .5.2.47. The value of HPA Timer should be set 
equal to the value of the T3 113 timer associated with the last NCC page attempt. The remaining T3 1 13 timers should be 
set to values less than the last T3 11 3 timer (ie, less than the value of HPA_Timer), so that the MES does not abandon 
the paging process prematurely. Table 4.3.2 and figure 4.3.3 shows the required setting for HPA Timer for the case of 
two page attempts. 

The MES shall have the capability to know how long it has to respond to a page. When the MES receives a page from 
the NCC it shall set a "page response" timer to the value of HPA Timer and start a count down. The "page response" 
timer shall be stopped when the MES sends the Channel Request (Answer to Paging) message to the NCC. If the MES 
receives another page from the NCC before being able to respond to any page in the paging sequence (i.e., a second, 
third, fourth or fifth page attempt) the MES shall reset the "page response" timer to the value of HPA Timer and start 
the count down again. If the "page response" timer expires, the MES shall indicate to the user that the paging process 
has been terminated by the network and return to idle mode. 

Table 4.3.2 summarizes the parameters used by the paging process. 



Table 4.3.2: Summary of the Paging Process Parameters 



Parameter 


Description 


Element 


Range 


TPAG 


MSG Paging Timer. Wlien this 
timer expires tlie IVISC starts 
Til pa. 


MSG 


seconds to 1 
seconds 


Thpa 


MSG Higli Penetration Alerting 
timer. Tliis timer is an extended 
paging timer used to give tine 
user time to get tlie IVIES in 
advantaged mode if necessary 


MSG 


seconds to- 
1 20 seconds 


T3113a 
T3113b 
T3113C 
T3113d 
131 13e 


NGG Paging timers. Amount of 

time the NGG waits before 
sending another page attempt. If 
it is the last page attempt then it 
is the remaining HPA Timer time, 
if any, the MES has to respond to 
the page request (which is equal 
to the value of HPA Timer). 


NGG 


seconds to 
1 30 seconds 


HPA Timer 


Parameter broadcast on the S- 
BGGH that tells the user how 
long it has to respond to the last 
page request (clause 11.5.2.47). 
HPA Timer = duration of the last 
T31 13 timer. 


NGG 


seconds to 
1 30 seconds 


Number of 
Paging 
Attempts 


Number of Paging Attempts 


NGG 


1-5 attempts 



The NCC shall be capable of processing the Channel Request message response to the page starting from the first page 
attempt until the expiration of the T31 13 timer associated with the last page attempt. The NCC shall be capable of 
processing the Channel Request message response to the page starting from the first page attempt until the expiration of 
the T31 13 timer associated with the last page attempt. 

When the NCC sends the first page to the MES, the T3 1 1 3a timer is started. The T3 1 1 3a timer is stopped if the NCC 
receives a channel request message in response to the page. If the T31 13a timer expires however, the NCC sends 
another page to the MES (assuming that the paging process is configured to use at least two page attempts), starts the 
T31 13b timer and waits for a response from the MES to either page attempt. The NCC continues in this fashion until it 
receives a response to a page attempt or the timer associated with the last page attempt expires. 

The NCC shall terminate the paging process when the T3113 timer associated with the last page attempt expires. If the 
NCC receives a charmel request in response to a page after the last T3 1 13 timer has expired, the NCC shall ignore the 
channel request message. 
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The gateway MSC shall be capable of processing the SABM message response to the page starting from when the page 
request message is sent until the expiration of Thpa. 

When the MSC sends a page request message, the MSC shall start timer TPAG. If TPAG expires, the MSC shall start 
timer Thpa. When the MSC receives an SABM message in response to a page, the MSC shall stop the TPAG or Thpa 
timer, whichever one is counting down, and proceed with the call. 

The gateway shall clearthe call if Thpa expires. 

The MSC timers, TPAG and Thpa, and the NCC T31 13 timers must be set in a coordinated fashion. The sum of the 
MSC timers shall be set slightly greater than the sum of the NCC timers, i.e., 

TPAG + Thpa > T3 113a + T31 13b + T3 113c + T31 13d + T31 13e. This relationship ensures that the MSC Thpa will not 
timeout before the NCC T31 13 timer associated with the last page attempt to allow for the time it takes for the network 
to complete the assigimient of an S-SDCCH, i.e., the time between when the MES sends the channel request message 
response (on the S-RACH) to the NCC and when the MES sends the SABM response (on the assigned S-SDCCH) to 
the gateway. 

The time relationships between the NCC and MSC paging timers and the parameter HPA Timer are illustrated in figure 
4.3.1 for the case of two page attempts. 



HPA Timer (04.008 Section 1 1 .5.2.47) 



NCC 
Page 
Request 
1 



NCC 
Page 
Request 
2 



T3113a 



T3113b 



G/W 
Request 

A 



TPAG 



Tfipa (fiigli penetration alerting timer) 



Figure 4.3.1 : Relationship of Timers Used for the Paging Process When Two Page Attempts are Used 



4.3.2.2 



Paging response 



When the MES receives a page from the NCC, the MES shall initiate the immediate assigimient procedure as specified 
in clause 4.3.1 within 0,7 second, exclusive of user interaction time. The establishment of the main signalling link is 
then initiated by use of an SABM with information field containing the PAGING RESPONSE message (see clause 
4.1.5). The MM sublayer in the MES is informed that a RR connection exists. 

Upon receipt of the CHANNEL REQUESTmessage the network stops the T3 113 timer. The MM sublayer in the 
network is informed that a RR connection exists. 



The following describes typical paging sequences. 

The normal paging sequence occurs when each step in the Paging Process is successful and takes less than TPAG 
seconds as shown in figure 4.3.2. 
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The gateway MSC initiates the Mobile Earth Station (MES) paging procedure by sending a PAGING message to the 
GSC and starts the timer, TP AG. The GSC then sends a PAGE COMMAND message to the NCC. The NCC initiates 
paging by broadcasting a Paging Request message in the appropriate S-HPACH block, and starts timer T3113a. When 
the MES receives the page, the MES will initiate the immediate assignment procedure with a CHANNEL REQUEST 
message response on the S-RACH. Upon receipt of CHANNEL REQUEST message, the network stops timer T3113a, 
and sends a CHANNEL REQUIRED message to the GSC. The GSC makes an S-SDCCH assignment, sends the 
assignment to the NCC in an IMMEDIATE ASSIGNMENT COMMAND message, and starts timer T3 101. The NCC 
sends an Immediate Assignment message to the MES. When the MES receives this message it tunes to the assigned 
channel and initiates the main signalling link by sending an SABM message with information field containing the 
Paging Response message. Upon receipt of the message, the TCE responds with a Layer 2 UA message which confirms 
that the main signalling link is established with the network. 

Upon receipt of the PAGING RESPONSE message, the GSC stops timer T3101 since a radio resource connection 
exists between the network and the MES. The GSC sends the Layer 3 information in the PAGING RESPONSE 
message to the MSC. Upon receipt, the MSC stops the TPAG and proceeds with the call. 



MES 



NCC 



PAQINQ REQUEST 



CHANNEL REQUEST 
> 



IMMEDIATE ASSIGNMENT (NCC) 
< 



SABM (PAGING RESPONSE) 



Start T3 11 3a 



Stop T3 11 3a 



PAGE COMMAND 
(GSC to NCC) 



CHANNEL REQUIRED 
> 



IMMEDIATE ASSIGNMENT 
COMMAND (GSC) 

< 



Gateway 



PAGING Msg 
(MSC to GSC) 

Start TPAG 



Start T3101 



StopT3101 
Stop TPAG 



Figure 4.3.2: Normal Paging Sequence 



A case where the response to the page is longer than TPAG seconds is shown in figure 4.3.3. This sequence is exactly 
the same as figure 4.3.2 except that TPAG expires and Thpa is started. When TPAG expires, the MSC starts Thpa and 
the Voice Prompt to the calhng party to inform them that the network is performing extend paging. When the MSC 
receives the PAGING RESPONSE message, it stops timer Thpa, stops the voice prompt, and starts the coimection 
process with the MES. 



ETSI 



GMR-2 04.008 



42 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



MES 



NCC 



Gateway 



PAGING REQUEST 



CHANNEL REQUEST 
> 



IMMEDIATE ASSIGNMENT (NCC) 
< 



SABM (PAQING RESPQNSE) 



Start T31 13a 



Stop T3113a 



PAQECQMMAND 
(QSC to NCC) 



CHANNEL REQUIRED 
> 

IMMEDIATE ASSIGNMENT 
COMMAND (GSC) 

< 



PAGING Msg 
(MSG to GSC) 

Start TPAG 



TPAG Expires 
Start Thpa 
Start Voice Prompt 



Start T3 101 



, StopT3101 

Stop Tlipa 
Stop Voice Prompt 



Figure 4.3.3: Normal Paging Sequence With Delay 

The normal paging sequences shown in figures 4.3.2 and 4.3.3 occur when each step in the paging sequence is 
successful. In reality, a number of occurrences in an operational system can cause changes in the paging sequence. A 
repeated paging sequence is shown in figure 4.3.4 using two paging attempts. 

If a PAGING REQUEST message is sent and timer T3 1 1 3a expires in the NCC without receipt of a valid CHANNEL 
REQUEST message, the NCC repeats the PAGING REQUEST message. 

If the MES is in disadvantaged mode, the MES may receive and decode paging messages from the NCC, however it 
cannot respond immediately. The MES signals the user that action is required to transition to advantaged mode (such as 
extending the antenna and/or going outside) before sending the CHANNEL REQUEST message. The reliance on 
operator interaction may cause the MES CHANNEL REQUEST message to reach the NCC after the timer T31 13a 
expires. In this case, the PAGING REQUEST message is repeated and timer T3 113b is started. If the CHANNEL 
REQUEST message is received by the NCC before T3113b expires, the NCC is able to successfully interpret the 
message as a response to the page and will respond as shown in figure 4.3.4. If not, the NCC is unable to correlate the 
message with the page because the paging process has been terminated and ignores the CHANNEL REQUEST 
message. 



MES 



NCC 



Gateway 
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PAGING REQUEST 



PAGING REQUEST 



CHANNEL REQUEST 
> 



IMMEDIATE ASSIGNMEf^ (NCC) 
SABM (PAGING RESPONSE) 



Start T31 13a 



Stop T3 113a 
Start T31 13b 



Stop T3113b 



PAGE COMMAND 
(GSCtoNCC) 



CHANNEL REQUIRED 
> 



IMMEDIATE ASSIGNMENT 
COMMAND (GSC) 



PAGING Msg 

(MSG to GSC) 

Start TPAG 



TPAG Expires 
Start Thpa 
Start Voice Prompt 



Start T31 01 



StopT3101 
Stop Thpa 
Stop Voice Prompt 



Figure 4.3.4: Repeated Paging Sequence 

When the MES is unable to respond to a paging request message, the timers in the NCC and MSC expire and the NCC 
and MSC terminate the paging process. This sequence is shown in figure 4.3.5. There is no exchange of messages 
between the NCC and the MSC to communicate that they have terminated the paging process. That is, when Thpa 
expires, the MSC stops the voice prompt and terminates the paging process. The MSC assumes the NCC has also 
terminated the paging process. When the last T31 13 timer in the NCC expires, the NCC terminates the paging process 
and assumes the MSC has also terminated the process. 



MES 



PAGING REQUEST 



PAGING REQUEST 



NCC 



start T31 13a 



Stop T3113a 
Start T31 13b 



T3113b Expires 
Paging Process 
Terminated 



PAGE COMMAND 
(GSCtoNCC) 



Gateway 



PAGING Msg 
(MSC to GSC) 

Start TPAG 



TPAG Expires 
Start Thpa 
Start Voice Prompt 



Thpa Expires 
Stop Voice Prompt 
Paging Process 
Terminated 



Figure 4.3.5: Paging Sequence With No iUlES Response 



4.3.2.3 Abnormal cases 

Lower layer failure occurring during the immediate assignment procedure is treated as specified for that procedure. 
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4.4.1.1 General 

In RR connected mode, the S-SACCH is used in signalling measurement results from the MES. 

The S-SACCH has the particularity that continuous transmission must occur in both directions. For that purpose, in the 
MES to network direction, measurement result messages are sent at each possible occasion when nothing else has to be 
sent (see clause 4.4.1.2). Similarly, the SYSTEM INFORMATION TYPE 6 message is sent in the network to the MES 
in UI frames when nothing else has to be sent. 

As specified in Technical Specification GMR-2 05.008 [26], problems occurring in the reception of S-SACCH frames 
are interpreted as a loss of communication and appropriate procedures are then triggered as specified in clause 4.5.2. 

4.4.1.2 Measurement report 

When in RR connected mode, the MES regularly sends MEASUREMENT REPORT messages to the network. These 
messages contain measurements results about reception characteristics from the current spotbeam. These measurement 
results are obtained as specified in Technical Specification GMR-2 05.008 [26]. These messages are sent on the satellite 
slow ACCH (S-SACCH), in unacknowledged mode. If no other message is scheduled on the S-SACCH at the instant 
when a Layer 2 frame is due to be sent, then the MES shall send a MEASUREMENT REPORT message in that frame. 
The interval between two successive Layer 2 frames containing MEASUREMENT REPORT messages shall not exceed 
one Layer 2 frame. 

4.4.2 Transfer of messages and link layer service provision 

When a RR connection is established, upper layers can send messages in multiframe or unacknowledged mode on 
SAPI 0. Moreover, upper layers have access to the full link layer services for SAPIs other than 0, with the exception of 
the error indication and local end release that are directly treated by the RR sublayer, as specified in particular places of 
clause 4. 

4.4.3 Channel assignment procedure 

An intraspotbeam change of channel can be requested by upper layers for changing the channel type, or decided by the 
RR sublayer, e.g., for an internal handover. This change may be performed through the dedicated channel assignment 
procedure. The purpose of the channel assigimient procedure is to completely modify the physical charmel 
configuration of the MES without change in synchronization while staying in the same spotbeam. 

This procedure shall not be used for changing between dependent configurations, i.e., those sharing Radio Resource. 

The channel assignment procedure happens only in RR connected mode. This procedure cannot be used in the idle 
mode; in this case the immediate assignment procedure is used. 

The channel assignment procedure includes: 

a) The suspension of normal operation except for RR management (Layer 3); 

b) The release of the main signalling link, and of the other Data Links as defined in clause 4.1.4, and the 

disconnection of S-TCHs, if any; 

c) The deactivation of previously assigned channels (Layer 1); 

d) The activation of the new channels and their coimection if applicable; 

e) The triggering of the establishment of the Data Link coimections for SAPI = 0. 
The channel assignment procedure is always initiated by the network. 
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4.4.3.1 



Channel assignment initiation 



The network initiates the channel assignment procedure by sending an ASSIGNMENT COMMAND message to the 
MES on the main signalling link. It then starts timer T3107. 

When sending this message on the network side, and when receiving it on the MES side, all transmission of signalling 
layer messages except for those RR messages needed for this procedure and for abnormal cases is suspended until 
resumption is indicated. These RR messages can be deduced from clauses 4.4.3 and 9.8 Radio Resource management. 

Upon receipt of the ASSIGNMENT COMMAND message, the MES initiates a local end release of link layer 
connections, disconnects the physical channels, commands the switching to the assigned channels and initiates the 
establishment of lower layer connections (this includes the activation of the charmels, their connection and the 
establishment of the main signalling links). 

The ASSIGNMENT COMMAND message contains the description of the new configuration and the exact satellite 
ACCHs to be used and a power command. The power level defined in this power command shall be used by the MES 
for the initial power on the new channel(s). It shall not affect the power used on the old channel(s). 

The ASSIGNMENT COMMAND message may contain a cipher mode setting IE. In that case, this mode has to be 
apphed on the new channel. If no such information is present, the ciphering mode is the same as on the previous 
channel. In either case, the ciphering key shall not be changed. The ASSIGNMENT COMMAND message shall not 
contain a cipher mode setting IE that indicates "start ciphering" unless a CIPHERING MODE COMMAND message 
has been transmitted earlier in the RR connection. If such an ASSIGNMENT COMMAND message is received, it shall 
be regarded as erroneous, an ASSIGNMENT FAILURE with cause "Protocol error unspecified" message shall be 
returned immediately, and no further action taken. 



After the main signalling link is successfully established, the MES returns an ASSIGNMENT COMPLETE message, 
specifying cause "normal event," to the network on the main S-DCCH. The sending of this message on the MES side 
and its receipt on the network side allow the resumption of the transmission of signalling layer messages other than 
those belonging to RR management. 

At the receipt of the ASSIGNMENT COMPLETE message, the network releases the previously allocated resources and 
stops timer T3107. 

4.4.3.3 Abnormal cases 

If the ASSIGNMENT COMMAND message instructs the MES to use a Channel Description or Mode that it does not 
support, then the MES shall return an ASSIGNMENT FAILURE message with cause "channel mode unacceptable," 
and the MES shall remain on the current channel(s) and uses the old Channel Description or Channel Mode. 

If the ASSIGNMENT COMMAND message instructs the MES to use a frequency that it is not capable of, then the 
MES shall return an ASSIGNMENT FAILURE message with cause "frequency not implemented," and the MES shall 

remain on the current channel(s). 

On the MES side, if a lower layer failure happens on the new channel before the ASSIGNMENT COMPLETE message 
has been sent, the MES deactivates the new channels, reactivates the old channels, reconnects the S-TCHs if any and 
triggers the establishment of the main signalling link. It then sends a ASSIGNMENT FAILURE message, cause 
"protocol error unspecified" on the main S-DCCH and resumes the normal operation, as if no assignment attempt had 
occurred. The operational parameters (e.g., ciphering mode) when returning on the old channel are those applied before 
the procedure. 

When receiving the ASSIGNMENT FAILURE message, the network stops T3107. If a lower layer failure happens 
while attempting to connect back to the old channels, the radio link failure procedure is applied (see clause 4.5.2). 

On the network side, if timer T3 107 elapses before either the ASSIGNMENT COMPLETE message has been received 
on the new channels, an ASSIGNMENT FAILURE message is received on the old channels, or the MES has re- 
established the call, the old channels and the new channels are released and aU contexts related to the connections with 
that MES are cleared. 



4.4.3.2 



Assignment completion 
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On the network side, lower layer failure occurring on the old channels after the sending of the ASSIGNMENT 
COMMAND message are ignored. Lower layer failures occurring after the receipt of the SABM Frame on the new 
main signalling link are treated following the general rules (see clause 4.5.2). 

4.4.4 Handover procedure 

This clause does not apply to the GMR-2 system. 

4.4.5 Frequency redefinition procedure 

This clause does not apply to the GMR-2 system. 

4.4.6 Cliannel mode modify procedure 

Higher layers can request a change of the channel mode. The channel mode modify procedure allows the network to 
request the MES to change the channel mode for one channel. The channel mode covers the coding, decoding and 
transcoding mode used on the indicated channel. 

This procedure is always initiated by the network. 

4.4.6.1 Initiation of the channel mode modify procedure 

The network initiates the procedure by sending a CHANNEL MODE MODIFY message to the MES. This message 
contains: 

a) A channel description of the channel on which the CHANNEL MODE MODIFY message is sent; and 

b) The new mode to be used on the channel. 

4.4.6.2 Completion of mode change procedure 

When it has received the CHANNEL MODE MODIFY message, the MES changes the mode for the indicated channel 
and then replies by a CHANNEL MODE MODIFY ACKNOWLEDGE message indicating the new channel mode. 

4.4.6.3 Abnormal cases 

No specific action for a lower layer failure is specified in this clause. If the MES does not support the indicated mode, it 
shall retain the old mode and return the associated channel mode information in the CHANNEL MODE MODIFY 
ACKNOWLEDGE message. 

4.4.7 Cipiierlng mode setting procedure 

The ciphering mode setting procedure is used by the network to set the ciphering mode, i.e., whether or not the 
transmission is ciphered, and if so, which algorithm to use. The procedure shall only be used to change from "not 
ciphered" mode to "ciphered" mode, or vice-versa, or to pass a CIPHERING MODE COMMAND message to the MES 
while remaining in the "not ciphered" mode. The ciphering mode setting procedure is always triggered by the network 
and it only applies to dedicated resources. 

4.4.7.1 Ciphering mode setting initiation 

The network initiates the ciphering mode setting procedure by sending a CIPHERING MODE COMMAND message to 
the MES on the main signalling link, indicating whether ciphering shall be used or not, and if yes, which algorithm to 
use. Additionally, the network may, by the use of the cipher response information element, request the MES to include 
its IMEISV in the CIPHERING MODE COMPLETE message. The new mode is applied for reception on the network 
side after the message has been sent. 
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4.4.7.2 Ciphering mode setting completion 

Whenever the MES receives a vaHd CIPHERING MODE COMMAND message, it shall load the ciphering key stored 
on the SIM. A vahd CIPHERING MODE COMMAND message is defined to be one of the following: 

a) One that indicates "start ciphering" and is received by the MES in the "not ciphered" mode; 

b) One that indicates "no ciphering" and is received by the MES in the "not ciphered" mode; or 

c) One that indicates "no ciphering" and is received by the MES in the "ciphered" mode. 

Other CIPHERING MODE COMMAND messages shall be regarded as erroneous, an RR STATUS message with 
cause "Protocol error unspecified" shall be returned, and no further action taken. 

Upon receipt of the CIPHERING MODE COMMAND message indicating ciphering, the MES shall start transmission 
and reception in the indicated mode. 

When the appropriate action on the CIPHERING MODE COMMAND has been taken, the MES sends back a 
CIPHERING MODE COMPLETE message. If the "cipher response" field of the cipher response information element in 
the CIPHERING MODE COMMAND message specified "IMEI must be included" the MES shall include its IMEISV 
in the CIPHERING MODE COMPLETE message. 

Upon receipt of the CIPHERING MODE COMPLETE message or any other correct Layer 2 frame which was sent in 
the new mode, the network starts transmission in the new mode. 



MES 




Network 




CIPH MOD CMD 


start reception In new mode 


start transmission and reception 


< 

CIPHER MODE COMPLETE 


start transmission In new mode 


in new mode 


> 





Figure 4.4.1 : Ciphering iUlode Setting Sequence 



4.4.8 Additional channel assignment procedure 

This clause does not apply to the GMR-2 system. 

4.4.9 Partial channel release procedure 

This clause does not apply to the GMR-2 system. 

4.4. 1 Classmark change procedure 

This procedure allows the MES to indicate to the network a change in the classmark (e.g., due to addition of power 
amplification). The MES sends a CLASSMARK CHANGE message to the network. This message contains the new 
MES classmark 2 information element. There is no acknowledgement at Layer 2 when the user terminal is in a mobile- 
to-mobile single hop connection. 

4.4.1 1 Classmark interrogation procedure 

This procedure allows the network to request additional classmark information from the MES (e.g., if the information 
initially sent by the MES is not sufficient for network decisions). This procedure shall not be used after a mobile-to- 
mobile single hop connection is established through the satellite. 

4.4.1 1 .1 Classmark interrogation initiation 

The network initiates the classmark interrogation procedure by sending a CLASSMARK ENQUIRY message to the 
MES on the main S-DCCH. 
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4.4.1 1 .2 Classmark interrogation completion 

On receipt of the CLASSMARK ENQUIRY message the MES sends a CLASSMARK CHANGE message to the 
network on the main S-DCCH. This message contains the MES classmark 2 information element. 

4.5 RR connection release procedure 

4.5.1 Normal release procedure 

The release of the RR connection can be requested by upper layers. The purpose of this procedure is to deactivate all the 
dedicated channels in use. When the channels are released, the MES returns to the S-CCCH configuration, idle mode. 
The channel release procedure can be used in a variety of cases, including S-TCH release after a call release, and S- 
DCCH release when a dedicated channel allocated for signalling is released. The channel release procedure is always 
initiated by the network. 

4.5.1.1 Channel Release Procedure Initiation 

The network initiates the channel release by sending a CHANNEL RELEASE message to the MES on the main S- 
DCCH, starts timer T3109 and deactivates the S-SACCH. On receipt of a CHANNEL RELEASE message the MES 
starts timer T31 10 and discoimects the main signalling link. When T31 10 times out, or when the disconnection is 
confirmed, the MES deactivates all channels, considers the RR connection as released, and returns to idle mode. 

NOTE: Data Links other than the main signalling link are disconnected by local end link release. 

On the network side, when the main signalling link is disconnected, the network stops timer T3109 and starts timer 
T3 1 1 1 . When timer T3 1 1 1 times out, the network deactivates the channels, they are then free to be allocated to another 
connection. 

NOTE: The sole purpose of timer T3 1 1 1 is to let some time to acknowledge the disconnection and to protect the 
channel in case of loss of the acknowledge frame. 

If timer T3109 times out, the network deactivates the channels. They are then free to be allocated to another coimection. 

The CHANNEL RELEASE message will include an RR cause indication as follows: 

a) #0 if it is a normal release, e.g., at the end of a call or at normal release of a S-DCCH; 

b) #1 to indicate an unspecified abnormal release; 

c) #2, #3 or #4 to indicate a specific release event; 

d) #8 to indicate a network activated Local Transmit Disable. Upon receipt of a Local Transmit Disable cause, the 
MES shall provide a Local Transmit Disable indication to the User. 

4.5.1.2 Abnormal cases 

Abnormal cases are taken into account in the main part of the description of the procedure. 

4.5.2 Radio link failure 

The main part of these procedures concerns the "normal" cases, i.e., those without any occurrence of loss of 
communication means. A separate clause at the end of the description of each procedure treats the cases of loss of 
communication, called a radio link failure. In RR connected mode, in most of the cases the reaction of the User 
Terminal or the network is the same. Those reactions are described in this clause to avoid repetitions. 

A radio link failure can be detected by several ways: 

a) By analysis of reception at Layer 1, as specified in GMR-2 05.008 [26] and clause 4.4.1.1; 

b) By a Data Link layer failure as specified in GMR-2 04.006 [15], on the main signalhng link. A Data Link failure 
on any other Data Link shall not be considered as a radio link failure; 
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c) When a lower layer failure happens while the MES attempts to connect back to the old channels in a channel 

assignment procedure; 

d) In some cases where timers are started to detect the lack of answer from the other party, described in clause 4. 
The two first cases are known by the term "lower layer failure." 

4.5.2.1 Mobile side 

When a radio link failure is detected by the MES: 

a) The MES shall perform a local end release on all signalling links unless otherwise specified; 

b) The MES shall deactivate aU channels; 

c) The RR sublayer of the MES shall indicate an RR coimection failure to the MM sublayer unless otherwise 
specified. 

NOTE: Upper layers may decide on a re-establishment (see clause 6.5.4). 

4.5.2.2 Network side 

In RR connected mode, the reaction of the network to a lower layer failure depends on the context. Except when 
otherwise specified, it is to release the connection either with the channel release procedure as specified in clause 4.5.1, 
or with the following procedure. The network starts timer T3109 and deactivates the S-SACCH (and hence to stop 
transmission on the S-SACCH). 

When a radio link failure has been detected, an indication is passed to the upper Mobility Management sublayer on the 
network side. 

When timer T3109 expires, the network can regard the channels as released and free for allocation. This procedure 
relies on the fact that if a MES does not receive the S-SACCH for some time, it completely releases the channels (see 
GMR-2 05.008 [26]). 

4.5.3 RR connection abortion 

The MES aborts the RR connection by initiating a normal release of the main signalling hnk, performing local end 
releases on all other signalling links and discoimecting all traffic channels, if any. 

4.6 Receiving a RR STATUS message by a RR entity. 

If the RR entity of the MES receives a RR STATUS message, no transition and no specific action shall be taken as seen 
from the radio interface, i.e., local actions are possible. The actions to be taken on receiving a RR STATUS message in 
the network are an implementation dependent option (see also clause 9). 
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5 Elementary procedures for mobility management 
5.1 General 

This clause describes the procedures used for Mobility Management at the radio interface (Reference Point Um). 

The main function of the Mobility Management sublayer is to support the mobiUty of MESs, such as informing the 
network of its present location and providing user identity confidentiality. 

A further function of the MM sublayer is to provide connection management services to the different entities of the 
upper Connection Management (CM) sublayer (see GMR-2 04.007 [16]). 

All the MM procedures described in this clause can only be performed if a RR connection has been established between 
the User Terminal and the Network. Else the MM sublayer has to initiate the establishment of a RR connection 
according to the procedures specified in clause 4.3. 

5.1 .1 Type of MM Procedures 

Depending on how they can be initiated, three types of MM procedures can be distinguished: 

1) MM common procedures: 

A MM common procedure can always be initiated while a RR coimection exists. The procedures belonging to 

this type are: 

i) Initiated by the network: 

ii) Authentication procedure; 

iii) Identification procedure; 

2) MM specific procedures: 

A MM specific procedure can only be initiated if no other MM specific procedure is miming or no MM 
connection exists. The procedures belonging to this type are: 

a) normal location updating procedure; 

b) periodic updating procedure; 

3) MM connection management procedures: 

These procedures are used to establish, maintain and release a MM connection between the MBS and the 
Network, over which an entity of the upper CM layer can exchange information with its peer. A MM connection 
establishment can only be performed if no MM specific procedure is ruiming. More than one MM connection 
may be active at the same time. 

5.1 .2 MM sublayer states 

The description of the states for the MM sublayer is organized as follows. The main states for the MES side, related to 
the procedures, are described in clause 5.1.2.1.1. The MM IDLE state is subdivided in substates for the description of 
the behavior in idle mode (clause 5.1.2.1.2). This behavior depends on an update status, described in clause 5.1.2.2. The 
states for the network side are described in clause 5.1.2.3. 

5.1 .2.1 MM sublayer states in the MES 

In this clause the possible states for the MM sublayer in the Mes is described. In figure 5.1.1 an overview of the MM 
sublayer protocol is given. 
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5.1.2.1.1 Main states 

NULL 

The MES is inactive (e.g., power down). Important parameters are stored. Only manual action by the user may 
transfer the MM sublayer to another state. 

3 LOCATION UPDATING INITIATED 

A location updating procedure has been started and the MM awaits a response from the network. The timer 
T3210 is running. 

5 WAIT FOR OUTGOING MM CONNECTION 

The MM connection establishment has been started, and the MM awaits a response from the network. The timer 
T3230 is running. 

6 MM CONNECTION ACTIVE 

The MM sublayer has a RR connection to its peer entity on the network side. One or more MM coimections are 

active. 

7 IMSI DETACH INITIATED 

9 WAIT FOR NETWORK COMMAND 

The MM sublayer has a RR connection to its peer entity in the network, but no MM connection is established. 
The MES is passive, awaiting fiirther commands from the network. The timer T3240 may be ruiming. 

10 LOCATION UPDATE REJECTED 

A location updating procedure has been rejected and RR connection release is awaited. The timer T3240 is 
running. 
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Figure 5.1.1 : Overview mobility management protocol / MES side 



13 WAIT FOR RR CONNECTION (LOCATION UPDATING) 

The MM sublayer has requested RR connection establishment for starting the location updating procedure. 

14 WAIT FOR RR CONNECTION (MM CONNECTION) 

The MM sublayer has requested RR connection establishment for starting the MM connection establishment. 

15 WAIT FOR RR CONNECTION (IMSI DETACH) 

17 WAIT FOR REESTABLISH 

18 WATT FOR RR ACTIVE 

The MM sublayer has requested activation of the RR sublayer. 

19 MM IDLE 

There is no MM procedure running and no RR connection exist. This is a compound state, and the actual 
behavior of the MES to Connection Management requests is determined by the actual substate as described 
hereafter. 

20 WATT FOR ADDITIONAL OUTGOING MM CONNECTION 

The MM connection establishment for an additional MM coimection has been started, and the MM awaits 
response from the network. 
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5.1 .2.1 .2 Substates of the MM idle state 

For the description of the behaviour of the MES in the MM IDLE state is subdivided in several substates, also called the 
service states. The service state pertains to the whole MES (ME-MES alone if no SIM is inserted, or ME-MES plus 
SIM.). The service state depends on the update status (see clause 5.1.2.2) and on the selected spotbeam. 

19.1 NORMAL SERVICE 

Valid subscriber data are available, update status is Ul, a spotbeam is selected that belongs to the LA where 
the subscriber is registered. In this state, all requests from the CM layers are treated normally. 

19.2 ATTEMPTING TO UPDATE 

Valid subscriber data are available, update status is U2 and a spotbeam is selected. Requests from upper 
layers are accepted. Emergency call requests are treated normally, otherwise the request triggers first a 
location updating attempt in the selected spotbeam, and then triggers the needed procedure only in case of 
successful location updating, otherwise the request is rejected 

19.3 LIMITED SERVICE 

Valid subscriber data are available, update status is U3, and a spotbeam is selected, which is known not to be 
able to provide normal service. Only emergency services are offered. 

19.4 NO IMSI 

No valid subscriber data (no SIM, or the SIM is not considered valid by the ME-MES), and a spotbeam is 
selected. No services are offered. 

19.5 NO SPOTBEAM AVAILABLE 

No spotbeam can be selected. This state is entered after a first intensive search failed (state 19.7). Spotbeams 
are searched at a low rhythm. No services are offered. 

19.6 LOCATION UPDATE NEEDED 

Valid subscriber data are available, and for some reason a location updating must be done as soon as 
possible, for instance update status is Ul but the selected spotbeam is not in the registered LA, or the timer 
has expired. This state is usually of no duration, but can last, e.g., in the case of access class blocking. 

19.7 PLMN/PSMN SEARCH 

The MES is searching for PLMNs, and the conditions for state 19.8 are not met. This state is ended when 
either a cell is selected (the new state is 19.1, 19.3 or 19.6), or when it is concluded that no cell is available 
for the moment (the new state is 19.5). 

19.8 PLMN/ PSMN SEARCH, NORMAL SERVICE 

Valid subscriber data are available, update status is Ul, a cell is selected which belongs to the LA where the 
subscriber is registered, and the MES is searching for PLMNs. This state is ended when either a cell is 
selected (the new state is 19.1, 19.3 or 19.6), or when it is concluded that no cell is available for the moment 
(the new state is 19.5). 

5.1.2.2 Update Status 

In parallel with the sublayer states described in clause 5.1.2.1 and which control the MM sublayer protocol, an update 
status exists. The update status pertains to a specific subscriber embodied by a SIM. This status is defined even when 
the subscriber is not activated (SIM removed or connected to a switched-off ME). It is stored in a non volatile memory 
in the SIM. The update status is changed only as a result of a location updating procedure attempt (with the exception of 
an authentication failure and of some cases of CM service rejection). 

Ul UPDATED 

The last location updating attempt was successful (correct procedure outcome, and the answer was acceptance 
from the network). With this status, the SIM contains also the LAI of the LA where the subscriber is registered, a 
ciphering key and ciphering key sequence number. The "Location update status" stored on the SIM be "updated." 
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U2 NOT UPDATED 

The last location updating attempt made failed procedurally (no significant answer was received from the 
network, including the cases of failures or congestion inside the network) For this status, the SIM does not 
contain any valid LAI, ciphering key or ciphering key sequence number. For compatibility reasons, all these 
fields must be set to the "deleted" value at the moment the status is set to NOT UPDATED. However the 
presence of other values shall not be considered an error by the User Terminal. The "Location update status" 
stored on the SIM shall be "not updated." 

U3 ROAMING NOT ALLOWED 

The last location updating attempt ran correctly, but the answer from the network was negative (because of 
roaming or subscription restrictions). For this status, the SIM does not contain any valid LAI, ciphering key or 
ciphering key sequence number. For compatibility reasons, all these fields must be set to the "deleted" value at 
the moment the status is set to ROAMING NOT ALLOWED. However the presence of other values shaU not be 
considered an error by the MES. The "Location update status" stored on the SIM shall be "Location Area not 
allowed." 

5.1 .2.3 MM sublayer states on the network side 

1 IDLE 

The MM sublayer is not active. 

2 WAIT FOR RR CONNECTION 

The MM sublayer has received a request for MM connection establishment from the CM layer. A RR connection 
to the MES is requested from the RR sublayer (i.e., paging is performed). 

3 MM CONNECTION ACTIVE 

The MM sublayer has a RR connection to a MES. One or more MM connections are active. 

4 IDENTIFICATION INITIATED 

The identification procedure has been started by the network. The timer T3270 is running. 

5 AUTHENTICATION INITIATED 

The authentication procedure has been started by the network. The timer T3260 is running. 

6 TMSI REALLOCATION INITIATED 

7 CIPHERING MODE INITIATED 

The cipher mode setting procedure has been requested to the RR sublayer. 

8 WAIT FOR MOBILE ORIGINATED MM CONNECTION 

A CM SERVICE REQUEST message is received and processed, and the MM sublayer awaits the "opening 
message" of the MM connection. 

9 WAIT FOR REESTABLISHMENT 

5.2 Behaviour in IVIIVI IDLE state 

The MM IDLE state is entered when none of the MM procedures are running and no RR connection exists. It is left 
when one of the MM procedures are triggered or an RR connection is established. 

The specific behaviour in the MM IDLE state depends on the service state of the MES as described in clause 5.1.2.1.2. 
The service state depends in particular on the update status which is defined in clause 5.1.2.2. 

How an appropriate service state is chosen after power on is described in clause 5.2.1, and the specific behavior of the 
MES in MM IDLE state is described in clause 5.2.2. The service state chosen when the MM IDLE state is returned to 
from any state except NULL state is described in clause 5.2.3. 

It should be noted that transitions between the various MM idle states are caused by: 

a) results of procedures on RR connected mode (see clause 5.2.3); 

b) insertion or removal of the SIM; 

c) spotbeam selection/reselection (see also GMR-2 03.022 [10]); 
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d) Loss of coverage. 

How various MM procedures affect the service state and the update status is described in the detailed descriptions of the 
procedures in clauses 5.3 to 5.5. 

5.2.1 Primary service state selection 

5.2.1 .1 Selection of the service state after power on. 

When mobility management is activated after power-on, the service state is 19.7 PLMN/PSMN SEARCH. The detailed 
processing in this state is described in detail in GMR-2 03.022 [10] and GMR-2 05.008 [26], where procedures for 
power on and selection of PLMN/PSMN is described in detail. If the "Location update status" stored on the SIM is 
different from "updated," then the mobile shall act as if the "Location update status" stored on the SIM is "not updated." 

The service state when the PLMN/PSMN SEARCH state is left depends on the outcome of the search and on the 
presence of the SIM: 

a) If no spotbeam has been found, the state is NO SPOTBEAM AVAILABLE, until a spotbeam is found; 

b) If no SIM is present the state is NO IMSI; 

c) If the MES has been continuously activated since loosing coverage and then returns to coverage, and if the selected 
spotbeam is in the location area where the MES is registered and the timer T3212 has not expired, then the state is 
NORMAL SERVICE; 

d) If the selected spotbeam is in the location area where the MES is registered and timer T3212 has not expired, then 
the state is NORMAL SERVICE; 

e) If the MES is in automatic network selection mode and the selected spotbeam is in a forbidden PLMN or a 
forbidden LA, then the User Terminal enters the LIMITED SERVICE state; 

f) If the MES is in manual network selection mode and no spotbeam has been found, then the MES enters the 
LIMITED SERVICE state; 

g) Otherwise, the MES enters the LOCATION UPDATE NEEDED state. 

5.2.1.2 Other cases 

The state PLMN SEARCH is also entered in the following cases: 

a) In state NO IMSI, a SIM is inserted; 

b) In any state except NO IMSI, NO SPOTBEAM AVAILABLE and NORMAL SERVICE, after the user has asked 
for a PLMN selection/PSMN; 

c) In any state except NO IMSI and NO SPOTBEAM AVAILABLE, coverage is lost; 

d) National roaming is denied; 

e) Optionally, when the MES is in the ATTEMPTING TO UPDATE state and is in Automatic Network Selection 
mode, after 3 minutes or after 6 unsuccessful LOCATION UPDATING REQUEST messages have been sent. 

The service state when the PLMN/PSMN SEARCH is left depends on the outcome of the search and on the presence of 
the SIM as specified in clause 5.2.1.1. 

5.2.2 Detailed description of the IVIES behaviour in MM IDLE state 

In the MM IDLE state the MES shall behave according to the service state. In the following clauses the behaviour is 
described for the non-transient service states. It should be noted that after procedures in RR connected mode, e.g., 
location updating procedures, clause 5.2.3 applies which specifies the selection of the MM idle state. Furthermore when 
in sub-state NORMAL SERVICE, if a PLMN/PSMN selection is requested, the MES enters sub-state PLMN/PSMN 
SEARCH, NORMAL SERVICE. 
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5.2.2.1 Service state, NORMAL SERVICE 

When in state MM IDLE and service state NORMAL SERVICE, the MES shall: 

a) Perform normal location updating when a new location area is entered; 

b) Perform location updating procedure at expiration of timer T321 1 or T3213; 

c) Perform periodic updating at expiration of timer T3212; 

d) Support requests from the CM layer; 

e) Respond to paging. 

5.2.2.2 Service state, ATTEMPTING TO UPDATE. 

When in state MM IDLE and service state ATTEMPTING TO UPDATE, the MES shall: 

a) Perform location updating procedure at expiration of timer T321 1 or T3213; 

b) Perform normal location updating when a new spotbeam is entered or the location area identification of the serving 

spotbeam is changed; 

c) Perform normal location updating at expiration of timer T3212; 

d) Support request for emergency calls; 

e) Use other request from CM layer as triggering of normal location updating procedure (if the location updating 
procedure is successful, then the request for MM connection is accepted, see clause 4.5.1); 

f) Respond to paging (with IMSI). 

5.2.2.3 Service state, LIMITED SERVICE 

When in state MM IDLE and service state LIMITED SERVICE, the MES shall: 

a) Not perform periodic updating; 

b) Reject any requests from CM entities for MM coimections except for emergency calls; 

c) Perform normal location updating when a spotbeam is entered which may provide normal service (e.g., location 
area not in one of the forbidden LAI lists.); 

d) Respond to paging (with IMSI). 

5.2.2.4 Service state, NO IMSI 

When in state MM IDLE and service state NO IMSI, the MES shall (see clause 4.2 of the present document, 
GMR-2 03.022 [10] and GMR-2 05.008 [26]): 

a) Not start any normal location updating attempt; 

b) Not perform periodic updating; 

c) Reject any request from CM entities for MM cormections; 

d) Not respond to paging; 

e) Only perform default spotbeam selection. 
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5.2.2.5 Service state, SEARCH FOR PLMN/PSMN, NORMAL SERVICE 

When in state MM IDLE and service state SEARCH FOR PLMN/PSMN, NORMAL SERVICE, the MES shall: 

a) If timer T321 1 or T323 expires in this state perform a location updating procedure if and when back to 
NORMAL SERVICE state and if the spotbeam is not changed; 

b) If timer T3212 expires in this state perform a periodic location updating procedure if and when back to 
NORMAL SERVICE state; 

c) Support requests from the CM layer; 

d) Listen as far as possible to paging, and respond. 

5.2.2.6 Service state, SEARCH FOR PLMN/PSMN 

When in state MM IDLE and service state SEARCH FOR PLMN/PSMN, the MES shall: 

a) Not start any normal location updating attempt; 

b) Not perform periodic updating; 

c) Reject any request from CM entities for MM coimections except emergency calls; 

d) Not respond to paging. 

5.2.3 Service state when back to state MM IDLE from another state 

When returning to MM IDLE, e.g., after a location updating procedure, the MES selects the spotbeam as specified in 
GMR-2 03.022 [10]. With one exception, this is a normal spotbeam selection. 

If this return to idle state is not subsequent to a location updating procedure terminated with reception of cause 
"National roaming not allowed in this location area" the service state depends on the result of the spotbeam selection 
procedure, on the update status of the MES, on the location data stored in the MES and on the presence of the SIM: 

a) If no spotbeam has been found, the state is NO SPOTBEAM AVAILABLE, until a spotbeam is found; 

b) If no SIM is present, or if the inserted SIM is considered invalid by the MES, the state is NO IMSI; 

c) If the selected spotbeam is in the location area where the MES is registered, then the state is NORMAL 
SERVICE; it shall be noted that this also includes an abnormal case described in clause 5.4.4.9; 

d) If the selected spotbeam is in a location area where the MES is not registered but in which the MES is allowed to 
attempt a location update, then the state is LOCATION UPDATE NEEDED; 

e) If the selected spotbeam is in a location area where the MES is not allowed to attempt a location update, then the 
state is LIMITED SERVICE; 

f) After some abnormal cases occurring during an unsuccessful location updating procedure, as described in clause 
5.4.4.9, the state is ATTEMPTING TO UPDATE. 

In case of a return from a location updating procedure to which was answered "National roaming not allowed in this 
location area," the service state PLMN/PSMN SEARCH is entered as specified in clause 5.2.1.2. 
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5.3 



MM common procedures 



As described above, a MM common procedure can be initiated at any time while a RR connection exists between the 
Network and the MES. 



This clause does not apply to the GMR-2 system. 

5.3.2 Authentication procedure 

The purpose of the authentication procedure is twofold: 

a) First to permit the network to check whether the identity provided by the MES is acceptable or not (see 
GMR-2 03.020 [9]); 

b) Second to provide parameters enabling the MES to calculate a new ciphering key. 

The cases where the authentication procedure should be used are defined in GMR-2 02.009 [4]. 
The authentication procedure is always initiated and controlled by the network. 

5.3.2.1 Authentication request by the network 

The network initiates the authentication procedure by transferring an AUTHENTICATION REQUEST message across 
the radio interface and starts the timer T3260. The AUTHENTICATION REQUEST message contains the parameters 
necessary to calculate the response parameters (see GMR-2 03.020 [9]). It also contains the ciphering key sequence 
number allocated to the key which may be computed from the given parameters. 

5.3.2.2 Authentication response by the MES 

The MES shall be ready to respond upon an AUTHENTICATION REQUEST message at any time whilst a RR 
connection exists. It shall process the challenge information and send back an AUTHENTICATION RESPONSE 
message to the network. The new ciphering key calculated from the challenge information shall overwrite the previous 
one and be stored on the SIM before the AUTHENTICATION RESPONSE message is ttansmitted. The ciphering key 
stored in the SIM shall be loaded in to the ME-MES when any valid CIPHERING MODE COMMAND is received 
during an RR connection (the definition of a valid CIPHERING MODE COMMAND message is given in clause 
4.4.7.2). The ciphering key sequence number shall be stored together with the calculated key. 

5.3.2.3 Authentication processing in the network 

Upon receipt of the AUTHENTICATION RESPONSE message, the network stops the timer T3260 and checks the 
validity of the response (see GMR-2 03.020 [9]). 

5.3.2.4 Ciphering key sequence number 

The security parameters for authentication and ciphering are tied together in sets, i.e., from a challenge parameter 
RAND both the authentication response SRES and the ciphering key can be computed given the secret key associated to 



In order to allow start of ciphering on a RR connection without authentication, the ciphering key sequence numbers are 
inttoduced. The sequence number is managed by the network in the way that the AUTHENTICATION REQUEST 
message contains the sequence number allocated to the key which may be computed from the RAND parameter carried 

in that message. 

The MES stores this number with the key, and indicates to the network in the first message (LOCATION UPDATING 
REQUEST, CM SERVICE REQUEST, PAGING RESPONSE) which sequence number the stored key has. When the 
deletion of the sequence number is described this also means that the associated key shall be considered as invaUd. 

The network may choose to start ciphering with the stored key (under the restrictions given in GMR-2 02.009 [4]) if the 
stored sequence number and the one given from the MES are equal. 



5.3.1 



TMSI reallocation procedure 



the IMSI. 



ETSI 



GMR-2 04.008 



59 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



5.3.2.5 Unsuccessful authentication 

If authentication fails, i.e., if the response is not valid, the Network assumes the IMSI was used. 

If the IMSI has been used, or the network decides not to try the identification procedure, an AUTHENTICATION 
REJECT message should be transferred to the MES. 

After having sent this message, all MM connections in progress (if any) are released and the network should initiate the 
RR connection release procedure described in clause 4.5. 

Upon receipt of an AUTHENTICATION REJECT message, the MES shall set the update status in the SIM to 
ROAMING NOT ALLOWED, LAI and ciphering key sequence number, and consider the SIM invalid until switched- 
off or the SIM is removed. 

If the IMSI provided by the MES is not known to the HLR, there will not be any sending of AUTHENTICATION 
REJECT message towards the mobile, but the call will be cut off using the CM SERVICE REJECT Message. 

5.3.2.6 Abnormal cases 

a) RR connection failure: 

Upon detection of a RR connection failure before the AUTHENTICATION RESPONSE is received, the 
network shall release all MM coimections (if any) and abort any ongoing MM specific procedure. 

b) Expiration of timer T3260: 

The authentication procedure is supervised on the Network side by the timer T3260. At expiration of this timer, 
the network may release the RR connection. In this case the network shall abort the authentication procedure and 
any ongoing MM specific procedure, release all MM connections if any, and initiate the RR connection release 
procedure described in clause 4.5. 





MES 

AUTHENTICATION REQUEST 


Network 

Start T3260 




< 

AUTHENTICATION RESPONSE 


Stop T3260 




(A) 

AUTHENTICATION REJECT 






(B) 




(A) : 
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Authentication; 
Autlientication Rejection. 





Figure 5.3.1: Authentication sequence 



5.3.3 Identification procedure 

The identification procedure is used by the Network to request a MES to provide specific identification parameters to 
the network. 

The identification procedure is used to request the IMSI inside an inter VLR location update procedure, if the IMSI 
caimot be retrieved ftom the previous VLR 

The identification procedure is also used to request the IMEI or IMEISV during an OC, a TC, or a SMS-MT when a 
system parameter is set. 
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5.3.3.1 Identity request by the network 

The network initiates the identification procedure by transferring an IDENTITY REQUEST message to the User 
Terminal and starts the timer T3270. The IDENTITY REQUEST message specifies the requested identification 
parameters in the identity type information element. 

5.3.3.2 Identification Response by the MES 

The MES shall be ready to respond to an IDENTITY REQUEST message at any time while a RR connection exists. 

Upon receipt of the IDENTITY REQUEST message the MES sends back an IDENTITY RESPONSE message. The 
IDENTITY RESPONSE message contains the identification parameters as requested by the network. 

Upon receipt of the IDENTITY RESPONSE the network shall stop timer T3270. 

5.3.3.3 Abnormal Cases 

a) RR connection failure: 

Upon detection of a RR connection failure before the IDENTITY RESPONSE is received, the network shall 
release all MM coimections (if any) and abort any ongoing MM specific procedure. 

b) Expiration of timer T3270: 

The identification procedure is supervised by the network by the timer T3270. At expiration of the timer T3270, 
the network may release the RR connection. In this case, the network shall abort the identification procedure and 
any ongoing MM specific procedure, release all MM connections if any, and initiate the RR connection release 
procedure as described in clause 3.5. 



MES 




Network 




IDENTIFICATION REQUEST 


Start T3270 




< 

IDENTIFICATION RESPONSE 


Stop T3270 




> 





Figure 5.3.2: Identification sequence 



5.3.4 IMS! detach procedure 

This clause does not apply to the GMR-2 system 

5.3.5 Abort procedure 

This clause does not apply to the GMR-2 system 

5.4 MM specific procedures 

A MM specific procedure can only be started if no other MM specific procedure is running or no MM connection exists 
between the network and the MES. The end of the running MM specific procedure or the release of all MM connections 
have to be awaited before a new MM specific procedure can be started. 

During the lifetime of a MM specific procedure, if a MM connection establishment is requested by a CM entity, this 
request will either be rejected or be delayed until the running MM specific procedure is terminated (this depends on the 
implementation) . 

Any MM common procedure may be initiated during a MM specific procedure. 
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Unless it has specific permission from the network (follow-on proceed), the MES side should await the release of the 
RR connection used for a MM specific procedure before a new MM specific procedure or MM connection 
establishment is started. 

NOTE: The network side may use the same RR connection for MM connection management. 

5.4.1 Location updating procedure 

The location updating procedure is a general procedure which is used for the following purposes: 

a) normal location updating (described in this clause); 

b) periodic updating (see clause 5.4.2); 

The normal location updating procedure is used to update the registtation of the actual Location Area of a MES in the 
network. The location updating type information element in the LOCATION UPDATING REQUEST message shall 
indicate normal location updating. The conditions under which the normal location updating procedure is used by a 
MES in the MM IDLE state are defined for each service state in clause 5.2.2. 

The normal location updating procedure shall also be started if the network indicates that the MES is unknown in the 
VLR as a response to MM connection establishment request. 

To limit the number of location updating attempts made, where location updating is unsuccessful, an attempt counter is 
used. The attempt counter is reset when a MES is switched on or a SIM card is inserted. 

Upon successful location updating, the MES sets the update status to UPDATED in the SIM, and stores the received 
Location Area Identification in the SIM. The attempt counter shall be reset. 

The detailed handling of the attempt counter is described in clauses 5.4.4.6 to 5.4.4.9. 

The Mobile Equipment shall contain a Ust of "forbidden location areas for national roaming," as well as a list of 
"forbidden location areas for regional provision of service." These lists shall be erased when the MES is switched off, 
when the SIM is removed, and periodically (with period in the range 12 hours to 24 hours). The location area 
identification received on the S-BCCH that triggered the location updating request shall be added to the suitable list 
whenever a location update reject message is received with the cause "National roaming not allowed in this location 
area" or with the cause "Location Area not allowed." The Usts shall each accommodate 10 or more location area 
identifications. When the list is full and a new entty has to be inserted, the oldest entty shall be deleted. 

The spotbeam selection processes in the different states are described in GMR-2 03.022 [10] and GMR-2 05.008 [26]. 

The location updating procedure is always initiated by the MES. 

5.4.2 Periodic updating 

Periodic updating may be used to notify periodically the availability of the MES to the network. Periodic updating is 
performed by using the location updating procedure. The location updating type information element in the 
LOCATION UPDATING REQUEST message shall indicate periodic updating. 

The procedure is controlled by the timer T3212 in the MES. If the timer is not already started, the timer is started each 
time the MES enters the MM IDLE substate NORMAL SERVICE or ATTEMPTING TO UPDATE. The timer T3212 
is stopped when the MES leaves the MM IDLE state. 

The timer is stopped and reset to when: 

a) A LOCATION UPDATING ACCEPT or LOCATION UPDATING REJECT message is received; 

b) The first MM message is received, or ciphering mode setting is completed in the case of MM connection 
establishment; 

c) The MES has responded to paging and thereafter has received the first correct layer 3 message except RR 

message; 

d) The timer has expired; 

e) The MES is deactivated (i.e., equipment powered down or SIM removed). 
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When the timer reaches the T3212 time-out value, the location updating procedure is started. 

The conditions under which the periodic location updating procedure is used by a MES in the MM IDLE state are 
defined for each service state in clause 5.2.2. 

If the MES is in service state NO SPOTBEAM AVAILABLE, LIMITED SERVICE, PLMN/PSTN SEARCH or 
PLMN/PSTN SEARCH-NORMAL SERVICE when the timer expires, the location updating procedure is delayed until 
this service state is left. The (periodic) location updating procedure is not started if the S-BCCH information at the time 
the procedure is triggered indicates that periodic location shall not be used. The time-out value is broadcast in the 
SYSTEM INFORMATION TYPE 3 message on the S-BCCH, in the Control channel description IE (see clause 
11.5.2.11). 

The T3212 time-out value shall not be changed in the NO SPOTBEAM AVAILABLE, LIMITED SERVICE, 
PLMN/PSTN SEARCH and PLMN/PSTN SEARCH-NORMAL SERVICE states. 

When a change of the T3212 time-out value has to be taken into account and the timer is running (at change of the 
serving spotbeam or, change of the broadcast value of T3212), the MES shall behave as follows: 

- Let tl be the new T3212 time-out value and let t be the current timer value at the moment of the change to the 
new T3212 time-out value; then the timer shall be restarted with the value t modulo tl. 

When the MES is activated, or when a change of the T3212 time-out value has to be taken into account and the timer is 
not miming, the MES shall behave as follows: 

- Let tl be the new T3212 time-out value, the new timer shall be started at a value randomly, uniformly drawn 
between and tl. 

5.4.3 IMSI attach procedure 

This clause does not apply to the GMR-2 system. 

5.4.4 Generic location updating procedure 
5.4.4.1 Location updating initiation by tine MES 

Any timer used for triggering the location updating procedure (e.g., T3211, T3212) is stopped if ruiming. 

As no RR connection exists at the time when the location updating procedure has to be started, the MM sublayer within 
the MES will request the RR sublayer to establish a RR connection and enter state WAIT FOR RR CONNECTION 
(LOCATION UPDATE). The procedure for establishing an RR connection is described in clause 4.3. 

The MES initiates the location updating procedure by sending a LOCATION UPDATING REQUEST message to the 
network, starts the timer T3210 and enters state LOCATION UPDATING INITIATED. The location updating type 
information element shall indicate what kind of updating is requested. 

5.4.4.1 a Network request for additional MES capability information 

This clause does not apply to the GMR-2 system. 

5.4.4.2 Identification request from the network 

The network may initiate the identification procedure (see clause 5.3.3). 

5.4.4.3 Authentication by the network 

The authentication procedure (see clause 5.3.2) may be initiated by the network upon receipt of the LOCATION 
UPDATING REQUEST message from the MES. (See the cases defined in GMR-2 02.009 [4]). 

The authentication procedure may be triggered by the VLR at each radio contact with the MES as specified in 
GSM 03.020 [9]. 
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5.4.4.4 



Ciphering mode setting by tine network 



The ciphering mode setting procedure (see clause 4.4.7) may be initiated by the network. 

A system shall indicate in the VLR whether the location update procedure has to be systematically ciphered or not. 



To limit the number of location updating attempts made, where location updating is unsuccessful, an attempt counter is 
used. It counts the number of consecutive unsuccessful location update attempts. 

The attempt counter is incremented when a location update procedure fails. The specific situations is specified in clause 



The attempt counter is reset when: 

a) The MES is powered on; 

b) A SIM is inserted; 

c) Location update is successfully completed; 

d) Location update completed with cause #1 1, #12 or #13 (see clause 5.4.4.7); 
and in case of service state ATTEMPTING TO UPDATE: 

a) A new location area is entered; 

b) Expiration of timer T3212; 

c) location update is triggered by CM sublayer requests. 

The attempt counter is used when deciding whether to re-attempt a location update after time-out of timer T321 1. 



If the location updating is accepted by the Network a LOCATION UPDATING ACCEPT message is transferred to the 
MES. 

If the Network wishes to prolong the RR connection to allow the MES to initiate MM connection establishment (for 
example if the MES has indicated in the LOCATION UPDATING REQUEST that it has a follow-on request pending), 
the network shall send "follow on proceed" in the LOCATION UPDATING ACCEPT and start timer T3255. 

The MES receiving a LOCATION UPDATING ACCEPT message shall store the received location area identification 
LAI, stop timer T3210, reset the attempt counter and set the update status in the SIM to UPDATED. 

If the LAI or PLMN identity contained in the LOCATION UPDATING ACCEPT message is a member of any of the 
"forbidden lists" then any such entries shall be deleted. 

After that, the MES shall act according to the presence of the Follow-on proceed information element in the 
LOCATION UPDATING ACCEPT; if this element is present and the MES has a CM appHcation request pending, it 
shall send a CM SERVICE REQUEST to the network and proceed as in clause 5.5.1.1. Otherwise, it shall start timer 
T3240 and enter state WAIT FOR NETWORK COMMAND. 

The MES identity shall not be sent in the LOCATION UPDATING ACCEPT. 



5.4.4.5 



Attempt counter 



5.4.4.9. 



5.4.4.6 



Location Updating Accepted by tine Network 
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5.4.4.7 



Location updating not accepted by tine network 



If the location updating cannot be accepted, the network sends a LOCATION UPDATING REJECT message to the 
MES. The MES receiving a LOCATION UPDATING REJECT message shall stop the timer T3210, store the reject 
cause, start T3240, enter state LOCATION UPDATING REJECTED await the release of the RR connection triggered 
by the network. Upon the release of the RR connection, the MES shall take the following actions depending on the 
stored reject cause: 

# 2 (IMSI unknown in HLR); 

# 3 (lUegal MES); 

# 6 (lUegal ME-MES). 

The MES shall set the update status to ROAMING NOT ALLOWED (and store it in the SIM according to clause 
4. 1.2.2), and delete any stored LAI and ciphering key sequence number and shall consider the SIM as invalid until 

switch-off or the SIM is removed. 

# 8 (Local Transmit Disable); 

# 11 (PLMN not allowed); 

#12 (Location Area not allowed); 

# 13 (National roaming not allowed in this location area). 

The cause "PLMN not allowed" shall be sent to a MES belonging to a foreign PLMN or to another national PLMN, but 
not allowed to roam outside its HPLMN. This cause shall also apply to the case where the foreign PLMN is unknown to 
the network. 

The MES shall delete any LAI and ciphering key sequence number stored in the SIM, reset the attempt counter, set the 
update status to ROAMING NOT ALLOWED (and store it in the SIM according to clause 5.1.2.2). The MES shall 
store the LAI or PLMN identity in the suitable forbidden list, i.e., in the "forbidden PLMN list" for cause #1 1, in the list 
of "forbidden location areas for regional provision of service" for causes # 8 and #12, and in the list of "forbidden 
location areas for national roaming" for cause #13. In addition for cause #8, the MES shall provide a Local Transmit 
Disable indication to the User. Further, the MES will memorize if cause #13 was received, so as to perform a PLMN 
selection instead of a spotbeam selection when back to the MM IDLE state. 

Other values are considered as abnormal cases and the specification of the MES behavior in those cases is given in 
clause 5.4.4.9. 



When the Location updating procedure is finished (see clauses 5.4.4.6 and 5.4.4.7), the MES shall (except in the case 
where the MES has a follow-on CM application request pending and has received the follow-on proceed indication, see 
clause 5.4.4.6) set timer T3240 and enter the state WAIT FOR NETWORK COMMAND, expecting the release of the 
RR connection. The network may decide to keep the RR connection for network initiated establishment of a MM 
connection, or to allow for mobile initiated MM connection establishment. 

Any release of the RR connection shall be initiated by the network according to clause 4.5. If the RR connection is not 
released within a given time controlled by the timer T3240, the MES shall abort the RR connection. In both cases, either 
after a RR connection release triggered from the network side or after a RR connection abort requested by the MES- 
side, the MES shall return to state MM IDLE. 

At transition to state MM IDLE, substates NORMAL SERVICE or ATTEMPTING TO UPDATE, either timer T3212 
or timer T321 1 is started as described in clause 5.4.4.9. 



5.4.4.8 



Release of RR connection after location updating 
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5.4.4.9 Abnormal cases on the MES side 

The different abnormal cases that can be identified are the following: 

a) Access barred because of access class control. 

The location updating procedure is not started. The MES stays in the current serving spotbeam and applies 
normal spotbeam reselection process. The procedure is started as soon as possible and if still necessary (when 
the barred state is ended or because of a spotbeam change); 

b) The answer to random access is an IMMEDIATE ASSIGNMENT REJECT message. 

The location updating is not started. The MES stays in the chosen spotbeam and applies normal spotbeam 
selection process. The waiting timer T3122 is reset when a spotbeam change occurs. The procedure is started as 
soon as possible after T3 122 time-out if still necessary; 

c) Random access failure 

Timer T3213 is started. When it expires, the procedure is attempted again if still necessary 

NOTE: As specified in GMR-2 05.008 [26], a spotbeam reselection then takes place with return to the spotbeam 
inhibited for 5 seconds. Typically the selection process will take the MES back to the spotbeam where the 
random access failed after 5 seconds. 

If random access failure occurs for two successive random access attempts for location updating, the MES 
proceeds as specified below; 

d) RR connection failure 

The procedure is aborted and the MES proceeds as specified below. If a RR-connection failure indication is 
reported to the MSG via the BSSMAP "Clear request" message with cause "O&M intervention," a LOCATION 
UPDATE REJECT message shall be sent by the MSG. The radio resource shall be released regardless of the 
cause value; 

e) T3210 time-out 

The procedure is aborted, the RR coimection is aborted and the MES proceeds as specified below; 

f) RR release before the normal end of procedure 

The procedure is aborted and the MES proceeds as specified below; 

g) Location updating reject, other causes than those treated in clause 5.4.4.7. The MES waits for release of the RR 
connection as specified in clause 5.4.4.8, and then proceeds as specified below. 

In cases d) to g) above, and for repeated failures as defined in c.) above, the MES proceeds as follows: Timer T3210 is 
stopped if still running. The RR Connection is aborted in case of timer T3210 time-out. The attempt counter is 
incremented. The next actions depend on the Location Area Identities (stored and received ftom the S-BCCH of the 
current serving spotbeam) and the value of the attempt counter: 

i) the update status is UPDATED, and the stored LAI is equal to the one received on the S-BCCH from the current 
serving spotbeam and the attempt counter is smaller than 4. The MES shall keep the update status to UPDATED, 
the MM IDLE sub-state after the RR connection release is NORMAL SERVICE. The MES shall memorize the 
location updating type used in the location updating procedure. It shall start timer T321 1 when the RR 
connection is released. When timer T321 1 expires the location updating procedure is triggered again with the 
memorized location updating type. 

ii) either the update status is different ftom UPDATED, or the stored LAI is different from the one received on the 
S-BCCH from the current serving spotbeam, or the attempt counter is greater or equal to 4. 

iii) The MES shall delete any LAI, ciphering key sequence number stored in the SIM, set the update status to NOT 
UPDATED and enter the MM IDLE sub-state ATTEMPTING TO UPDATE when the RR connection is 
released (See clause 4.2.2.2 for the subsequent actions). If the attempt counter is smaller than 4, the MES shall 
memorize that timer T321 1 is to be started when the RR connection is released, otherwise it shall memorize that 
timer T3212 is to be started when the RR connection is released. 
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5.4.4.1 Abnormal cases on the network side 

a) RR connection failure: 

i) If a RR connection failure occurs during a common procedure integrated with the location updating 
procedure, the behavior of the network should be according to the description of that common procedure; 

ii) If a RR connection failure occurs when a common procedure does not exist, the location updating procedure 
towards the MES should be aborted. 

b) Protocol error: 
See clause 9. 

5.5 Connection management sublayer service provision 

The concept of MM connection is introduced in this clause. This concept is mainly a descriptive tool: The establishment 
of an MM connection by the network and the release of an MM connection by the network or by the MES is always 
local, i.e., these purposes can be achieved without sending any MM messages over the air interface. (On the contrary, 
establishment of an MM coimection by the MES requires the sending of MM messages over the air interface.) 

The Mobility Management (MM) sublayer is providing connection management services to the different entities of the 
upper Connection Management (CM) sublayer (see GMR-2 04.007 [16]). It offers to a CM entity the possibility to use 
an MM connection for the exchange of information with its peer entity. An MM coimection is established and released 
on request from a CM entity. Different CM entities communicate with their peer entity using different MM connections. 
Several MM connections may be active at the same time. 

An MM connection requires an RR connection. All simultaneous MM connections for a given MES use the same RR 
connection. 

In the following clauses, the procedures for establishing, re-establishing, maintaining, and releasing an MM connection 
are described, usually separately for the MES and the network side. 

5.5.1 MM connection establishment 

A maximum of 8 MM coimections shall be supported at one time for a given MES. 

5.5.1 .1 MM connection establishment initiated by the MES 

Upon request of a CM entity to establish an MM connection, the MM sublayer first decides whether to accept, delay, or 
reject this request: 

1) A MM connection establishment may only be initiated by the MES when the following conditions are fulfilled: 

a) Its update status is UPDATED; 

b) The MM sublayer is in one of the states MM IDLE or MM CONNECTION ACTIVE. 

2) An exception from this general rule exists for emergency calls (see clause 5.5.1.5). A further exception is delined 
in the following clause. 

a) If an MM specific procedure is running at the time the request from the CM sublayer is received, and the 
LOCATION UPDATING REQUEST message has been sent, the request will either be rejected or delayed, 
depending on implementation, until the MM specific procedure is finished and, provided that the network has 
not sent a "follow-on proceed" indication, the RR connection is released. If the LOCATION UPDATING 
REQUEST message has not been sent, the MES may include a "follow-on request" indicator in the message. 
The MES shall then delay the request until the MM specific procedure is completed, when it may be given 
the opportunity by the network to use the RR connection (see clause 5.4.4.6). 

b) If an MM specific procedure is running at the time the request from the CM sublayer is received, and a 
CHANNEL REQUEST message of type Location Updating has been sent (see clause 10.1.8.7), the MES 
may not include a "follow-on request" indicator in the LOCATION UPDATING REQUEST mesage. 
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3) In order to establish an MM connection, the MES proceeds as follows: 

a) If no RR connection exists, the MM sublayer requests the RR sublayer to establish an RR connection and 
enters MM sublayer state WAIT FOR RR CONNECTION (MM CONNECTION). This request contains an 
establishment cause and a CM SERVICE REQUEST message. When the establishment of an RR connection 
is indicated by the RR sublayer (this indication implies that the CM SERVICE REQUEST message has been 
successfully transferred via the air interface, see clause 4.2), the MM sublayer of the MES starts timer T3230, 
gives an indication to the CM entity that requested the MM coimection establishment, and enters MM 
sublayer state WAIT FOR OUTGOING MM CONNECTION; 

b) If an RR connection is available, the MM sublayer of the MES sends a CM SERVICE REQUEST message to 
the network, starts timer T3230, gives an indication to the CM entity that requested the MM connection 
establishment, and enters: 

i) MM sublayer state WAIT FOR OUTGOING MM CONNECTION, if no MM connection is active; 

ii) MM sublayer state WAIT FOR ADDITIONAL OUTGOING MM CONNECTION, if at least one MM 
connection is active; 

iii) If an RR connection exists but the MES is in the state WATT FOR NETWORK COMMAND, then any 
requests from the CM layer that are received will either be rejected or delayed until this state is left. 

4) The CM SERVICE REQUEST message contains: 

a) Mobile identity according to clause 11.5.1.4; 

b) MES classmark 2; 

c) Ciphering key sequence number; 

d) CM service type identifying the requested type of transaction (e.g., MES originating call establishment, 
emergency call establishment, short message service and supplementary service activation). 

Upon receiving a CM SERVICE REQUEST message, the network shall analyze its content. The type of semantic 
analysis may depend on other on going MM connection(s). Depending on the type of request and the current status of 
the RR coimection, the network may start any of the MM common procedures and RR procedures. 

The GSC may initiate the classmark interrogation procedure, for example, to obtain further information on the MESs 
encryption capabilities. 

The network may invoke the authentication procedure (see clause 5.3.2) depending on the CM service type. 

The network decides also if the ciphering mode setting procedure shall be invoked (see clause 4.4.7). 

An indication from the RR sublayer that the ciphering mode setting procedure is completed, or reception of a CM 
SERVICE ACCEPT message, shall be treated as a service acceptance indication by the MES. The MM connection 
establishment is completed, timer T3230 shall be stopped, the CM entity that requested the MM connection shall be 
informed, and MM sublayer state MM CONNECTION ACTIVE is entered. The MM coimection is considered to be 
active. 

If the service request cannot be accepted, the network returns a CM SERVICE REJECT message to the MES. 

The reject cause information element (see clause 11.5.3.6 and Annex G) indicates the reason for rejection. The 
following cause values may apply: 

#4: IMSI unknown in VLR; 

#6; Illegal ME; 

#8: Local Transmit Disable 

#17: Network failure; 

#22: Congestion; 

#32: Service option not supported; 
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#33: Requested service option not subscribed; 

#34: Service option temporarily out of order. 

If no other MM connection is active, the network may start the RR connection release (see clause 4.5) when the CM 
SERVICE REJECT message is sent. 

If a CM SERVICE REJECT message is received by the MES, timer T3230 shall be stopped, the requesting CM 
sublayer entity informed. The MES shall then proceed as follows: 

a) If the cause value is not #4 , #6 or #8, the MM sublayer retums to the previous state (the state where the request was 
received). Other MM connections shall not be affected by the CM SERVICE REJECT message. 

b) If cause value #4 is received, the MES aborts any MM connection, deletes the LAI and ciphering key sequence 
number in the SIM, changes the update status to NOT UPDATED (and stores it in the SIM according to clause 
5. 1.2.2), and enters the MM sublayer state WAIT FOR NETWORK COMMAND. If subsequently the RR 
connection is released or aborted, this will force the MES to initiate a normal location updating. Whether the CM 
request shall be memorized during the location updating procedure is a choice of implementation. 

c) If cause value #6 is received, the MES aborts any MM connection, deletes the LAI and ciphering key sequence 
number in the SIM, changes the update status to ROAMING NOT ALLOWED (and stores it in the SIM according 
to clause 5.1.2.2), and enters the MM sublayer state WAIT FOR NETWORK COMMAND. The MES shall consider 
the SIM as invalid until switch-off or the SIM is removed. 

d) If cause value #8 is received, the MES aborts any MM conection, deletes the LAI and ciphering key sequence 
number stored in the SIM, changes the update status to ROAMING NOT ALLOWED (and stores it in the SIM 
according to clause 5.1.2.2) and stores the LAI in the list of "forbidden location areas for regional provision of 
service". In addition, the MES shall provide a Local Transmit Disable indication to the User. 

5.5.1.2 Abnormal cases 

MES side: 

a) RR connection failure or IMSI deactivation: 

If an RR connection failure occurs or the IMSI is deactivated during the establishment of an MM connection, the 
MM connection establishment is aborted, timer T3230 is stopped, and an indication is given to the CM entity 
that requested the MM connection establishment. This shall be treated as a rejection for establishment of the new 
MM connection, and the MM sublayer shall release all active MM connections; 

b) T3230 expiration: 

If T3230 expires (i.e., no response is given but a RR connection is available), the MM connection establishment 
is aborted and the requesting CM sublayer is informed. If no other MM connection exists, then the MES shall 
proceed as described in clause 4.5.3.1 for release of the RR connection. Otherwise, the MES shall return to the 
MM sublayer state where the request of an MM cormection was received, i.e., to MM sublayer state MM 
CONNECTION ACTIVE. Other ongoing MM connections (if any) shall not be affected; 

c) Reject cause values #95, #96, #97, #99, #100, #111 received: 

The same actions as on timer expiration shall be taken by the MES; 

d) Random access failure or RR connection establishment failure: 

If the MES detects a random access failure or RR connection establishment failure during the establishment of 
an MM connection, it aborts the MM connection establishment and gives an indication to the CM entity that 
requested the MM cormection establishment. 

NOTE: Further actions of the MES depend on the RR procedures and MM specific procedures during which the 
abnormal situation has occurred and are described together with those procedures. 

Network side: 

a) RR connection failure: 

The actions to be taken upon RR connection failure within a MM common procedure are described together with 
that procedure. A RR connection failure occurring outside such MM common procedures, shall trigger the release of 
all active MM connections if any; 
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b) Invalid message or message content: 

Upon reception of an invalid initial message or a CM SERVICE REQUEST message with invalid content, a CM 
SERVICE REJECT message shall be returned with one of the following appropriate Reject cause indications: 

# 95: Semantically incorrect message; 

# 96: Mandatory information element error; 

# 97: Message type non-existent or not implemented; 

# 99: Information element non-existent or not implemented; 

# 100: Conditional IE error; 
#111: Protocol error, unspecified. 

These causes will result in the MSC discarding the CM SERVICE REQUEST message received. The CM SERVICE 
REJECT shall not be generated in the corresponding case. 

If the CM SERVICE REQUEST message received contains the IMEI as the identity of the MES, however: 

a) The cause "Semantically incorrect message" shall be returned in the CM SERVICE REJECT message by the MSC; 

b) The cause "IMEI not accepted" shall be returned if the CM Service type indicated "Emergency call establishment." 

When the CM SERVICE REJECT message has been sent, the network may start RR connection release if no other MM 
connections exist or if the abnormal condition also has influence on the other MM connections. 



When a CM sublayer entity in the network requests the MM sublayer to establish a MM connection, the MM sublayer 
will request the establishment of an RR connection to the RR sublayer if no RR connection to the desired User Terminal 
exists. The MM sublayer is informed when the paging procedure is finished (see clause 5.3.2). 

When an RR connection is established (or if it already exists at the time the request is received), the MM sublayer may 
initiate any of the MM common procedures (except IMSI detach). The GSC may request the RR sublayer to perform 
the RR classmark interrogation procedure, and the MSC may request the ciphering mode setting procedure. 

When all MM and RR procedures are successfully completed which the network considers necessary, the MM sublayer 
will inform the requesting CM sublayer entity on the success of the MM connection establishment. 

If an RR connection already exists and no MM specific procedure is running, the network may also establish a new MM 
connection by sending a CM message with a new PD/TI combination. 

If the establishment of an RR connection is unsuccessful, or if any of the MM common procedures or the ciphering 
mode setting fail, this is indicated to the CM layer with an appropriate error cause. 

If an RR connection used for a MM specific procedure exists to the MES, the CM request may be rejected or delayed 
depending on implementation. When the MM specific procedure has been completed, the network may use the same 
RR connection for the delayed CM request. 

5.5.1.4 Abnormal cases 

The behaviour upon abnormal events is described together with the relevant RR procedure or MM common procedure. 



A MM connection for an emergency call may be established in all states of the mobility management sublayer which 
allow MM connection establishment for a normal originating call. In addition, establishment may be attempted in aU 
service states where a spotbeam is selected (see clause 5.2.2). However, as a network dependent option, a MM 
connection establishment for emergency call may be rejected in some of the states. Similarly as an option, a CM 
SERVICE REQUEST message for emergency call establishment relating to a MES not allowed to roam in the 
MSC/VLR area may be accepted. If the IMSI provided by the MES in the CM SERVICE REQUEST (or in a 
subsequent IDENTITY RESPONSE) message is not known in the VLR but allows to derive the HLR address in order 
to get the authentication data, and if the authentication procedure is performed successfully, the emergency call request 
is accepted. 



5.5.1.3 



MM Connection Establishment Initiated by the Network 



5.5.1.5 



MM connection establishment for emergency calls 
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When a user requests an emergency call establishment, the MES will send a CM SERVICE REQUEST message to the 
network with a CM service type information element indicating emergency call establishment. If the network does not 
accept the emergency call request, e.g., because IMEI was used as identification and this capability is not supported by 
the network, the network will reject the request by returning a CM SERVICE REJECT message to the MES. 

If the IMEI is provided as MES identity in the CM SERVICE REQUEST message, the error "IMEI not accepted" is 
returned in the CM-SERVICE-REJECT message. 

If the MES is blackhsted, the reject cause shall be "Illegal ME-MES." 

The reject cause information element indicates the reason for rejection. The following cause values may apply: 



#3: 


"Illegal MES" (Illegal MS-MES at MSC); 


#4: 


"IMSI unknown in VLR"; 


#5: 


"IMEI not accepted"; 


#6: 


"Illegal ME-MES"; 


#8: 


"Local Transmit Disable"; 


#17: 


"Network failure"; 


#22: 


"Congestion"; 


#32: 


"Service option not supported"; 


#34: 


"Service option temporarily out of order". 



With the above defined exceptions, the procedures described for MM connection establishment in clauses 5.5.1.1 and 
5.5.1.2 shall be followed. 

NOTE: Normally, the MES will be identified by an IMSI. However, if none of these identifiers is available in the 
MES, then the MES shall use the IMEI for identification purposes. The network may in that case reject 
the request by returning a CM SERVICE REJECT message with reject cause: #5 "IMEI not accepted". 

5.5.1.6 Call re-establishment 

This clause does not apply to the GMR-2 system. 

5.5.1 .7 Forced release during MO MM connection establishment 

If MESs CM layer initiated the MM connection establishment, but the CM layer wishes to abort the establishment prior 
to the completion of the establishment phase, the MES shall send a CM SERVICE ABORT message any time after the 
completion of the RR connection and not after the first CM message (e.g., SETUP) is sent. 

If the first CM message has akeady been sent, the normal release procedure defined by the appropriate CM protocol 
appUes and the CM SERVICE ABORT shall not be sent. 

Sending of the CM SERVICE ABORT message is only allowed during the establishment of the first MM connection, 
where no other MM connection exists in parallel. If parallel MM connections exist already, a new connection 
establishment cannot be aborted and normal MM connection release according to clause 5.5.3 applies after MM 
connection establishment. 

Upon transmission of the CM SERVICE ABORT message, the MES shall set timer T3240 and enter the state WAIT 
FOR NETWORK COMMAND, expecting the release of the RR connection. 

Upon receipt of the CM SERVICE ABORT message, the network shall abort ongoing processes, release the appropriate 
resources, and unless another MM connection establishment is pending, initiate a normal release of the RR connection. 

If the RR connection is not released within a given time controlled by timer T3240, the MES shall abort the RR 
connection. In both cases, either after a RR connection release triggered from the network side or after a RR connection 
abort requested by the MES side, the MES shall return to state MM IDLE, the service state depending upon the current 
update status as specified in clause 5.2.3. 
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5.5.2 MM connection information transfer phase 

After the MM connection has been established, it can be used by the CM sublayer entity for information transfer. 
According to the protocol architecture described in GMR-2 04.007 [16], each CM entity will have its own MM 
connection. These different MM connections are identified by the protocol discriminator PD and, additionally, by the 
transaction identifier (TI). 

All MM common procedures may be initiated at any time while MM coimections are active. Except for Short Message 
Control, which uses a separate layer 2 low priority data link, no priority mechanism is defined between the CM, MM 
and RR sublayer messages. 

A maximum of 8 MM-connections shall be supported in parallel. 

5.5.2.1 Sending CM messages 

A CM sublayer entity, after having been advised that a MM connection has been established, can request the transfer of 
CM messages. The CM messages passed to the MM sublayer are then sent to the other side of the interface with the PD 
and TI set according to the source entity. 

5.5.2.2 Receiving CM messages 

Upon receiving a CM message, the MM sublayer will distribute it to the relevant CM entity according to the PD value 
and TI value. However, if the received CM message is the first for the MM connection (identified by PD and TI), the 
MM sublayer will in addition indicate to the CM entity that a new MM connection has been established. 

5.5.2.3 Abnormal cases 

RR connection failure: 

If the RR connection failure occurs during a RR or MM common procedure, the consequent actions are described 
together with that procedure. 

In other cases the following apphes: 

MES: 

The MM sublayer shall indicate to all CM entities associated with active MM coimections that the MM 
connection is interrupted, the subsequent action of the MM sublayer (call re- establishment, see clause 
5.5.1.6, or local release) will then depend on the decisions by the CM entities. 

Network: 

The MM sublayer shall locally release all active MM connections. As an option the network may delay the 
release of all or some of the MM coimections to allow the MES to initiate call re-establishment. 

5.5.3 MM connection release 

An established MM connection can be released by the local CM entity. The release of the CM connection will then be 
done locally in the MM sublayer, i.e., no MM message are sent over the air interface for this purpose. 

5.5.3.1 Release of associated RR connection 

If all MM connections are released by their CM entities, the MES shall set timer T3240 and enter the state WATT FOR 
NETWORK COMMAND, expecting the release of the RR connection. 

In the network, if the last MM connection is released by its user, the MM sublayer may decide to release the RR 
connection by requesting the RR sublayer according to clause 4.5. The RR connection may be maintained by the 
network, e.g., in order to establish another MM connection. 

If the RR connection is not released within a given time controlled by the timer T3240, the MES shall abort the RR 
connection. In both cases, either after a RR connection release triggered from the network side or after a RR connection 
abort requested by the MES-side, the MES shall return to MM IDLE state, the service state depending upon the current 
update status as specified in clause 5.2.3. 
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6 



Elementary procedures for circuit-switched call 
control 



6.1 



Overview 



6.1.1 



General 



This clause describes the call control (CC) protocol, which is one of the protocols of the Connection Management (CM) 
sublayer (see GMR-2 04.007 [16]). 

Every MES must support the call control protocol. If a MES does not support any bearer capability at all, then it shall 
respond to a SETUP message with a RELEASE COMPLETE message as specified in clause 6.4. 

In the call control protocol, more than one CC entity are defined. Each CC entity is independent from each other and 
shall communicate with the correspondent peer entity using its own MM coimection. Different CC entities use different 

transaction identifiers. 

With a few exceptions, the present document describes the call control protocol only with regard to two peer entities. 
The call control entities are described as communicating finite state machines which exchange messages across the 
radio interface and communicate internally with other protocol (sub)layers. This description in only normative as far as 
the consequential externally observable behaviour is concerned. 

Certain sequences of actions of the two peer entities compose "elementary procedures" which are used as a basis for the 
description in this clause. These elementary procedures may be grouped into the following classes: 

Call establishment procedures; 

Call clearing procedures; 

Call information phase procedures; 

Miscellaneous procedures. 

The terms "mobile originating" or "mobile originated" (MO) are used to describe a CALL INITIATED by the MES. 
The terms "mobile terminating" or "mobile terminated" (MT) are used to describe a CALL INITIATED by the 
Network. 

Figure 6.1.1 gives an overview of the main states and transitions on the MES side. 
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Figure 6.1.1 : Overview of caii controi protocoi / iUIES side 

Figure 6.1.2 gives an overview of the main states and transitions on the network side. 
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Figure 6.1.2: Overview of call control protocol / network side 

6.1.2 Call control states 

6.1 .2.1 Call states at the user terminal side of the interface 

The states which may exist on the MES side of the radio interface are defined in this clause. 

NOTE: States UO. 1 , U26, and U27 are GSM/GMR specific. All other states are ITU-T defined. 

6.1.2.1.1 Null (State UO) 

No call exists. 

6.1 .2.1 .2 MM CONNECTION PENDING (State U0.1 ) 

This state exists for a mobile originating call, when the MES requests the establishment of a MM connection. 

6.1 .2.1 .3 CALL INITIATED (State U1 ) 

This state exists for a mobile originating call, when the MES requests call establishment from the network. 
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6.1 .2.1 .4 Mobile Originating Call Proceeding (State U3) 

This state exists for a mobile originating call, when the MES has received acknowledgement that the network has 
received all call information necessary to effect call establishment. 

6.1 .2.1 .5 Call Delivered (State U4) 

This state exists for a mobile originating call, when the calling MES has received an indication that remote user alerting 
has been initiated. 

6.1 .2.1 .6 Call Present (State U6) 

This state exists for a mobile terminating call, when the MES has received a call establishment request but has not yet 
responded. 

6.1 .2.1 .7 Call Received (State U7) 

This state exists for a mobile terminating call, when the MES has indicated alerting but has not yet answered. 

6.1 .2.1 .8 Connect Request (State U8) 

This state exists for a mobile terminating call, when the MES has answered the call and is waiting to be awarded the 
call. 

6.1 .2.1 .9 Mobile Terminating Call Confirmed (State U9) 

This state exists for a mobile terminating call, when the MES has sent acknowledgement that the MES has received all 
call information necessary to effect call establishment. 

6.1.2.1.10 Active (State U1 0) 

This state exists for a mobile terminating call, when the MES has answered the call. This state exists for a mobile 
originating call when the MES has received an indication that the remote user has answered the call. 

6.1 .2.1 .1 1 Disconnect Request (State U1 1 ) 

This state exists when the MES has requested the network to clear the end-to-end connection (if any) and is waiting for 
a response. 

6.1.2.1.12 Disconnect Indication (State U12) 

This state exists when the MES has received an invitation to disconnect because the network has disconnected the end- 
to-end connection (if any). 

6.1 .2.1 .13 Release Request (State U19) 

This state exists when the MES has requested the network to release and is waiting for a response. 

6.1 .2.1 .1 4 Mobile Originating Modify (State U26) 

This state exists when the MES has sent a request to the network for a new mode but has not yet received an answer. 

6.1 .2.1 .15 Mobile Terminating Modify (State U27) 

This state exists when the MES has received a request from the network for a new mode and has not yet sent a response 
to this request. 
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6.1.2.2 Network Call states 

The call states that may exist on the network side of the radio interface are defined in this clause. 

NOTE: States NO. 1 , N26, N27, N28, N3, N4, N7, and N9 are GSM/GMR specific. All other states are ITU-T 
defined. 

6.1.2.2.1 Null (State NO) 

No call exists. 

6.1 .2.2.2 MM CONNECTION PENDING (State N0.1 ) 

This state exists for a mobile terminating call, when the network requests the establishment of a MM connection. 

6.1 .2.2.3 CALL INITIATED (State N1 ) 

This state exists for a mobile originating call, when the network has received a call establishment request but has not yet 
responded. 

6.1 .2.2.4 Mobile Originating Call Proceeding (State N3) 

This state exists for a mobile originating call, when the network has sent acknowledgement that the network has 
received all call information necessary to effect call establishment. 

6.1 .2.2.5 Call Delivered (State N4) 

This state exists for a mobile originating call, when the network has indicated that remote user alerting has been 
initiated. 

6.1 .2.2.6 Call Present (State N6) 

This state exists for a mobile terminating call, when the network has sent a call establishment request but has not yet 
received a satisfactory response. 

6.1 .2.2.7 Call Received (State N7) 

This state exists for a mobile terminating call, when the network has received an indication that the MES is alerting but 
has not yet received an answer. 

6.1 .2.2.8 Connect Request (State N8) 

This state exists for a mobile terminating call, when the network has received an answer but the network has not yet 
awarded the call. 

6.1 .2.2.9 Mobile Terminating Call Confirmed (State N9) 

This state exists for a mobile terminating call, when the network has received acknowledgement that the MES has 
received all call information necessary to effect call establishment. 

6.1.2.2.10 Active (State N1 0) 

This state exists for a mobile terminating call, when the network has awarded the call to the called MES. This state 
exists for a mobile originating call when the network has indicated that the remote user has answered the call. 
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6.1.2.2.11 (Not Used) 

6.1.2.2.12 Disconnect Indication (State N12) 

This state exists when the network has disconnected the end-to-end connection (if any) and has sent an invitation to 
disconnect the MES to network connection. 

6.1 .2.2.1 3 Release request (State N1 9) 

This state exists when the network has requested the MES to release and is waiting for a response. 

6.1.2.2.14 Mobile Originating Modify (State N26) 

This state exists when the network has received a request from the MES for a new mode but has not yet sent a response. 

6.1 .2.2.1 5 Mobile Terminating Modify (State N27) 

This state exists when the network has sent a request to the MES for a new mode but has not yet received an answer. 

6.1 .2.2.1 6 Connect Indication (State N28) 

This state exists for a mobile originating call, when the network has indicated that the remote user has answered the call 
and the network is waiting for acknowledgement by the MES. 

6.2 Call establishment procedures 

Establishment of a call is initiated by request of upper layer in either the MES or the network. It consists of: 

- The establishment of a CC coimection between the MES and the Network; 

- The activation of the codec or interworking function. 

Whenever it is specified in clause 6 of the present document that the MES shall attach the user connection, this means 
that the MES shall activate the codec or interworking function as soon as an appropriate channel is available. The MES 
shall de-activate the codec or interworking function whenever an appropriate channel is no longer available. As soon as 
an appropriate chaimel is (again) available, the codec or interworking function shall be re-activated. If a new order to 
attach the user coimection is received, the new order shall supersede the previous one. 

A channel shall be considered as appropriate if it is consistent with the possibly negotiated bearer capability appUcable 
for the actual phase of the call. It is an implementation option whether the MES shall consider a channel as not 
appropriate if the type of channel (full rate/half rate) is not according to the radio channel requirements in the bearer 
capability. If: 

- The user connection has to be attached but no appropriate chaimel is available for a contiguous time of 30 
seconds; or if 

- The codec or interworking function is de-activated for a contiguous time of 30 seconds, then the MES may 
initiate call clearing. 

Upon request of upper layers to establish a call, restricting conditions for the establishment of the call are examined. 
These restricting conditions concern the states of parallel CC entities and are defined elsewhere. If these restricting 
conditions are fulfilled, the call establishment is rejected. Otherwise, a CC entity in state UO (NULL), is selected to 
establish the call. It initiates the establishment by requesting the MM sublayer to establish an MM connection. 
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6.2.1 Mobile originating call establishment 

The call control entity of the MES initiates establishment of a CC connection by requesting the MM sublayer to 
establish a mobile originating MM connection and entering the MM CONNECTION PENDING state. There are two 
kinds of a mobile originating call; basic call and emergency call. The request to establish an MM connection shall 
contain a parameter to specify whether the call is a basic or an emergency call. This information may lead to specific 
quahties of services to be provided by the MM sublayers. Timer T303 is started when the CM SERVICE REQUEST 
message is sent. 

While being in the MM CONNECTION PENDING state, the call entity of the MES may cancel the call prior to 
sending the first call control message according to the rules given in clause 5.5.1.7. 

6.2.1.1 Call Initiation 

Having entered the MM CONNECTION PENDING state, upon MM connection establishment, the call control entity of 
the MES sends a setup message to its peer entity. This setup message is: 

A SETUP message, if the call to be established is a basic call; or 

An EMERGENCY SETUP message, if the call to be established is an emergency call. 

It then enters the CALL INITIATED state. This state is supervised by timer T303, which has already been started after 
entering the MM CONNECTION PENDING state. 

The setup message shall contain all the information required by the network to process the call. In particular, the 
SETUP message shall contain the called party address information. 

When the call control entity of the MES is in the CALL INITIATED state and if it receives: 

a) A CALL PROCEEDING message, it shall proceed as described in clause 6.2.1.3; 

b) An ALERTING message, it shall proceed as described in clause 6.2.1.5; 

c) A CONNECT message, it shall proceed as described in clause 6.2.1.6; 

d) A RELEASE COMPLETE message it shall proceed as described in clause 6.2.1.2. 
Abnormal case: 

Since timer T303 is used to supervise the two consecutive states MM CONNECTION PENDING and CALL 
INITIATED, the expiration of timer T303 leads to different actions depending on the respective state: 

-If timer T303 elapses in the MM CONNECTION PENDING state, the MM connection in progress shall be aborted 
and the user shall be informed about the rejection of the call; 

-If timer T303 elapses in the CALL INITIATED state before any of the CALL PROCEEDING, ALERTING, 

CONNECT or RELEASE COMPLETE messages has been received, the clearing procedure described in clause 
6.4 is performed. 
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Figure 6.2.1 : Mobile originated call initiation and possible subsequent responses 
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6.2.1.2 Receipt of a setup message 

In the NULL state, upon receipt of a setup message (a SETUP message or an EMERGENCY SETUP message, see 
clause 6.2. LI), the call control entity of the network enters the "CALL INITL\TED" state. It shall then analyze the call 
information contained in the setup message: 

a) If, following the receipt of the setup message, the call control entity of the network determines that the call 
information received from the MES is invalid (e.g., invalid number), then the network shall initiate call clearing 
as defined in clause 6.4 with one of the following cause values: 

#1 : "unassigned (unallocated) number"; 

#3: "no route to destination"; 

#22: "number changed"; 

#28 : "invalid number format (incomplete number) " . 

b) If, following the receipt of the setup message, the call control entity of the network determines that a requested 
service is not authorized or is not available, it shall initiate call clearing in accordance with clause 6.4.2 with one 
of the following cause values: 

#8: "operator determined barring"; 

#57: "bearer capability not authorized"; 

#5 8 : "bearer capabiUty not presently available" ; 

#63: "service or option not available, unspecified"; 

#65: "bearer service not implemented". 

c) Otherwise, the call control entity of the network shall either: 

Send a CALL PROCEEDING message to its peer entity to indicate that the call is being processed and enter 
the MOBILE ORIGINATING CALL PROCEEDING state; 

Send an ALERTING message to its peer entity to indicate that alerting has been started at the called user 
side and enter the CALL RECEIVED state; 

Send a CONNECT message to its peer entity to indicate that the call has been accepted at the called user 
side and enter the CONNECT REQUEST state. 

The call control entity of the network may insert bearer capability information element(s) in the CALL PROCEEDING 
message to select options presented by the MES in the Bearer Capability information element(s) of the SETUP 
message. The bearer capability information element(s) shall contain the same parameters as received in the SETUP 
except those presenting a choice. Where choices were offered, appropriate parameters indicating the results of those 
choices shall be included. 

The call control entity of the network having entered the MOBILE ORIGINATING CALL PROCEEDING state, the 
network may initiate the assignment of a traffic channel according to clause 6.2.1.9 (early assignment). 

6.2.1 .3 Receipt of a CALL PROCEEDING message 

Having entered the CALL INITIATED state, when the call control entity of the MES receives a CALL PROCEEDING 
message, it shall stop timer T303 and start timer T310 unless: 

The CALL PROCEEDING message contains a progress indicator IE specifying progress description #1 or #2; or 

It has received a PROGRESS message containing a progress indicator IE specifying progress description #1 or #2 
prior to the CALL PROCEEDING message; 

and enter the MOBILE ORIGINATING CALL PROCEEDING state. 

Abnormal case: 

If timer T310 elapses before any of the ALERTING, CONNECT or DISCONNECT messages has been received, 
the MES shall perform the clearing procedure described in clause 6.4. 
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Figure 6.2.2: Call proceeding sequence at mobile originated call establishment 

6.2.1 .4 Notification of progressing mobile originated call 

In this clause, the term "interworking" is used only in the meaning of interworking with a network other than PLMN or 
ISDN, not as interworking between PLMN and ISDN since this is the normal case. In this sense, PLMN and ISDN are 
seen within the same environment, called the PLMN/ISDN environment. 

6.2.1 .4.1 Notification of interworking in connection with mobile originated call establishment 

During call establishment, the call may leave a PLMN/ISDN enviroimient, e.g., because of interworking with another 
network, with a non-PLMN/ISDN user, or with non-PLMN/ISDN equipment within the called user's premises. The call 
may also return to a PLMN/ISDN environment. When such situations occur, the network may send a progress indicator 
information element to the calling MES either: 

a) In an appropriate call control message, if a state change is required (e.g., ALERTING (values 1, 2, 8) or 
CONNECT); 

b) In the PROGRESS message, values 1 and 8, if no state change is appropriate. 

This progress indicator information element shall contain one of the following progress description values: 

a) #1 "call is not end-to-end PLMN/ISDN; further call progress information may be available in- band"; 

b) #2 "destination address is non-PLMN/ISDN"; 

c) #8 In-Band Information or appropriate pattern now available. 
See also clauses 6.5.1 and 6.5.6 for further reactions of the MES. 

6.2.1 .4.2 Call progress in the PLMN/ISDN environment 

In order to inform the MES that the call is progressing in the PLMN/ISDN environment, the network may send a 
progress indicator information element to the calling MES either: 

a) In an appropriate call control message, if a state change is required (e.g., ALERTING or CONNECT); 

b) In the PROGRESS message, if no state change is appropriate. 

This progress indicator information element shall contain progress description value #32 "Call is end-to-end 
ISDN/PLMN." See also clause 6.5.6 for further reactions of the MES. 

6.2.1.5 Alerting 

Having entered the MOBILE ORIGINATING CALL PROCEEDING state, upon receiving an indication that user 
alerting has been initiated at the called address, the call control entity of the network shaU send an ALERTING message 
to its peer entity at the calling MES and enter the "CALL DELIVERED" state. 

When the call control entity of the MES in the CALL INITIATED state or MOBILE ORIGINATING CALL 
PROCEEDING state receives an ALERTING message, then the call control entity of the MES shall stop timers T303 
and T310 (if running) and shall enter the CALL DELIVERED state. In this state, for speech calls, an alerting indication 
should be given to the user. If the MES has not attached the user connection, then the MES shall internally generate an 
alerting indication. If the MES has attached the user connection, then the network is responsible for generating the 
alerting indication and the MES need not generate one. 
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Abnormal cases: 

On the MES side, if timer T310 expires, the call control entity of the MES shall initiate call clearing as described in 
clause 6.4. 
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ALERTING 






< 





Figure 6.2.3: Call confirmation at mobile originating call establishment 



6.2.1.6 Call connected 

Upon receiving an indication that the call has been accepted, the call control entity of the network shall connect the 
traffic channel (including the connection of an interworking function, if required) and send a CONNECT message to its 
peer entity at the calling MES, start timer T313 and enter the CONNECT INDICATION state. This message indicates 
to the call control entity of the calling MES that a connection has been established through the network. 

The call control entity of the MES in the CALL INITL\TED state, in the MOBILE ORIGINATING CALL 
PROCEEDING state or in the CALL DELIVERED state, shall, upon receipt of a CONNECT message: 

Attach the user connection; 

- Return a CONNECT ACKNOWLEDGE message; 

Stop any locally generated alerting indication (if applied); 

- Stop timer T303 and T310 (if running); 

- Enter the ACTIVE state. 
Abnormal cases: 

On the MES side, if timer T303 or T310 expires, the call control entity of the MES shall initiate call clearing as 
described in clause 6.4. 

NOTE: The MES may have applied an additional internal alerting supervision which causes initiation of call 
clearing prior to the expiration of T303 or T3 10. 

The call control of the network in the CONNECT INDICATION state, shall, upon receipt of a CONNECT 
ACKNOWLEDGE message: 

- Stop timer T3 1 3 and enter the ACTIVE state. 
Abnormal cases: 

On the network side, if timer T313 elapses before a CONNECT ACKNOWLEDGE message has been received, the 
network shall perform the clearing procedure as described in clause 6.4. 
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Figure 6.2.4: Call acceptance sequence at mobile originating call establishment 

6.2.1.7 Call rejection 

Upon receiving an indication that the network or the called user is unable to accept the call, the network shall initiate 
call clearing at the radio interface to the mobile which originated the call, as described in clause 6.4 using the cause 
provided by the terminating network or the called user. 
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6.2.1 .8 Transit network selection 

This clause does not apply to the GMR-2 system. 

6.2.1 .9 Traffic cfiannel assignment at mobile originating call establishment 

The Network shall only support the early assignment of an appropriate traffic channel during the mobile originating call 
establishment phase. Initiation of a suitable RR procedure to assign an appropriate traffic channel does neither change 
the state of a call control entity nor affect any call control timer. 

NOTE: During certain phases of such an RR procedure, transmission of CC and MM messages may be 
suspended, see GSM 08.08 [29]. 

The assigimient procedure does not affect any call control timer. 

6.2.1 .10 Call Queuing at mobile originating call establishment 

The conditions to apply queuing are described in GMR-2 03.001 [6]. 

If an idle traffic channel is not available at the assignment instant, the network may place the traffic channel request in a 
queue. Calls arriving when all positions in the queue are occupied shall be cleared by the network using the cause #34 
"no circuit/channel available." Traffic channel allocation and queuing procedures are specified in GSM 08.08 [29]. 

An explicit queuing indicator is not provided to the MES. 

The maximum queuing interval is supervised by the network. The limit is a network dependent choice. In case the 
network is not able to allocate a traffic channel within the queuing Umit, the network will release the call using cause 
#34 "no circuit/channel available." 

Specific indications provided in the network to the remote user are a network dependent choice. 

6.2.2 Mobile terminating call establishment 

Before call establishment can be initiated in the MES, the MM coimection must be established by the network. 

6.2.2.1 Call indication 

After the arrival of a call from a remote user, the corresponding call control entity in the network shall initiate the MM 
connection establishment according to clause 5 and enter the MM CONNECTION PENDING state. The request to 
establish the MM connection is passed from the CM sublayer to the MM sublayer. It contains the necessary routing 
information derived from the SETUP message. 

Upon completion of the MM connection, the call control entity of the network shall send the SETUP message to its peer 
entity at the User Terminal, start timer T303 and enter the CALL PRESENT state. 

Upon receipt of a SETUP message, the MES shall perform compatibihty checking as described in clause 6.2.2.2. If the 
result of the compatibility checking was compatibility, the call control entity of the MES shall enter the CALL 
PRESENT state. An incompatible MES shall respond with a RELEASE COMPLETE message in accordance with 
clause 6.2.2.3.4. 

If no response to the SETUP message is received by the call control entity of the network before the expiration of timer 
T303, the procedures described in clause 6.2.2.3.3 shall apply. 
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> 

RELEASE COMPLETE (ii) 



Figure 6.2.5: Mobile terminating call initiation an possible subsequent responses 

6.2.2.2 Compatibility cliecking 

The MES receiving a SETUP message shall perform compatibility checking before responding to that SETUP message. 
Aimex B defines compatibihty checking to be performed by the MES upon receiving a SETUP message. 

6.2.2.3 Call confirmation 

6.2.2.3.1 Response to SETUP 

Having entered the CALL PRESENT STATE the call control entity of the MES shall, with the exception of the cases 
described below, acknowledge the SETUP message by a CALL CONFIRMED message, and enter the MOBILE 
TERMINATING CALL CONFIRMED state. 

The call control entity of the MES may include in the CALL CONFIRMED message to the network one or two bearer 
capability information elements to the network, either preselected in the MES or corresponding to a service dependent 
directory number (see GSM 09.07 [30]). The MES may also include one or two bearer capabilities in the CALL 
CONFIRMED message to define the radio channel requirements. In any case, the rules specified in clause 10.3.2.2 shall 
be followed. 

NOTE: The possibiUty of alternative responses (e.g., in connection with supplementary services) is for further 
study. 

A busy MES which satisfies the compatibility requirements indicated in the SETUP message shall respond either with a 
CALL CONFIRMED message, if the call setup is allowed to continue, or a RELEASE COMPLETE message if the call 
setup is not allowed to continue, both with cause #17 "user busy." 

If the mobile user wishes to refuse the call, a RELEASE COMPLETE message shall be sent with the cause #21 "call 
rejected." 

In the cases where the MES responds to a SETUP message with a RELEASE COMPLETE message, the MES shall 
release the MM cormection and enter the NULL state after sending the RELEASE COMPLETE message. 

The network shall process the RELEASE COMPLETE message in accordance with clause 6.4. 

6.2.2.3.2 Receipt of CALL CONFIRMED and ALERTING by the network 

The call control entity of the network in the CALL PRESENT state, shall, upon receipt of a CALL CONFIRMED 
message, stop timer T303, start timer T310 and enter the MOBILE TERMINATING CALL CONFIRMED state. 

The call control entity of the MES, having entered the MOBILE TERMINATING CALL CONFIRMED state, if the 
call is accepted at the called user side, the MES proceeds as described in clause 6.2.2.5. Otherwise, if the signal 
information element was present in the SETUP message, user alerting is initiated at the MES side. If the signal 
information element was not present in the SETUP message, user alerting is initiated when an appropriate chaimel is 
available. 

Here, initiation of user alerting means: 

a) The generation of an appropriate tone or indication at the MES; and 

b) Sending of an ALERTING message by the call control entity of the MES to its peer entity in the network. 
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With regards to the negotiable parameters of the BC 1 IE included in the SETUP message, the possible negotiated 
parameters returned by the MES in the CALL CONFIRM message (within the BC 1 IE) shall conform to Table 6.2.1. 



Table 6.2.1 : Table of negotiable GSM-BC parameters for the SETUP message from the CALL 

CONFIRMED message 



Parameters 


Parameter values f( 

^SC^ri ID nnA00onA 

OC 1 Ur meSSayG 


}r the relative messages 

OMLL LvwnriMM iTiessaye 


Number of Data Bits 


n1 


free choice 


Number of Stop Bits 


n2 


free choice 


rdlliy llllUllllclllUII 


no 


llcc OllUiOc \ilUlU %j) 


Radio Channel Requirement 
(RGB) 


arbitrary value (note 1) 


• (note 2) 

• 01 

• 11 


Connection Element (CE) 


• transparent 

• non transparent 

• UUliI, li cti lo|Jd.i CI 11 \ 1 } [JIclcIlcU 

• both, non transparent (NT) 

yj\ d CI 1 cu 


• transparent 

• non transparent 

• oclcULcU, lice UilUILrC 

• selected, free choice 


User Information Layer 2 
Protocol 


• for CE = T : NAV 

• for CE = NT or noth T/NT : 
offered value 


• for CE = T : ignored (forced to NAV) 

• for CE = NT : selected value for NAV 

(note 4) 


Structure 


unstructure or SDU 


• not controlled 

• forced to unstructured for CE=T 

• forced to SDU for CE=NT 


Intermediate Rate 


8 kbit/s or 16 kbit/s 


• not controlled 

• forced to 8 kbit/s if UR #9.6 kbit/s 

• forced to 1 6 kbit/s if CE=NT 

• else 16 kbit/s for CE=T 


User rate 


offered value 


• free choice according to values 
supported by the network (5) 


Modem Type 


V series 


• If CE=T : equal to the value 
corresponding to user rate, except for 
fax (where it is equal to none) 

• If CE=NT : not controlled, forced to 
the value corresponding to user rate 
(autobauding not supported). 


NOTE 1 : The value sent is always for 'Full Rate' 
NOTE 2 : 

• For Data Calls 

If the value 00, 1 or 11 is received, then the value of the {channel type} included in the BSSIVIAP 
{Assignment Request} message (refer to GSIVI 08.08 [29]) shall always indicate a 'Full Rate' channel. 

• For Speech Calls : 

Refer to Table 10.7.2 for a description of the RCR handling. 
NOTE 3 : It is controlled that for 8 data bits, the value of parity is « none ». Otherwise the call is released 
NOTE 4 : 

• For Asynchronous services the only values accepted are NAV (byte 7 absent), IA5 (in-band flow control) 

or {videotex profile 3} (no flow control) 

• For Synchronous services only the value X.25, is accepted by the network (NSC). 
NOTE 5: Always true for fax teleservice and according to an option for bearer services. 

NOTE 6: If no choice is done by the MS in its response (i.e. either a choice is returned in the GSM-BC or no GSM- 
BC is received in the call confirmed when a choice has been proposed in the setup) the call is released. 



The call control entity of the network in the MOBILE TERMINATED CALL CONFIRMED state shall, upon receipt of 
an ALERTING message, send a corresponding ALERTING indication to the calling user, stop timer T310, start timer 
T301, and enter the CALL RECEIVED state. 

In the MOBILE TERMINATING CALL CONFIRMED state or the CALL RECEIVED state, if the user of a MES is 
User Determined User Busy, then a DISCONNECT message shall be sent with cause #17 "user busy." In the MOBILE 
TERMINATING CALL CONFIRMED state, if the user of a MES wishes to reject the call then a DISCONNECT 
message shall be sent with cause #21 "call rejected." 
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6.2.2.3.3 Call failure procedures 

In case of abnormal behavior, the following call failure procedures apply: 

i) If the network does not receive any response to the SETUP message prior to the expiration of timer T303, then 
the network shall initiate clearing procedures towards the calling user with cause #18, "no user responding," 
and initiate clearing procedures towards the called MES in accordance with clause 6.4.4, using cause #102 
"recovery on timer expiration." 

ii) If the network has received a CALL CONFIRMED message, but does not receive an ALERTING, CONNECT 
or DISCONNECT message prior to the expiration of timer T310, then the network shall: 

Initiate clearing procedures towards the calling user with cause #18 "no user responding"; and 

Initiate clearing procedures towards the called MES in accordance with clause 6.4.4 using cause #102 
"recovery on timer expiration." 

iii) If the network has received an ALERTING message, but does not receive a CONNECT or DISCONNECT 
message prior to the expiration of timer T301 (or a corresponding internal alerting supervision timing 
function), then the network shall initiate clearing procedures towards the calling user with cause #19 "user 
alerting, no answer" and initiate clearing procedures towards the called MES in accordance with clause 6.4.4, 
using cause #102 "recovery on timer expiry" or using cause #31 "normal, unspecified." 

NOTE: The choice between cause #3 1 and cause #102 may have consequences on indications generated by the 
MES, see GSM 02.40 [5]. 

6.2.2.3.4 Called MES clearing during mobile terminating call establishment 
See clause 6.4.2. 

6.2.2.4 Notification of interworking in connection with mobile terminating call 
establishment 

In this clause, the term "interworking" is used only in the meaning of interworking with a network other than PLMN or 
ISDN, not as interworking between PLMN and ISDN since this is the normal case. In this sense, PLMN and ISDN are 
seen within the same enviroimient, called the PLMN/ISDN enviroimient. 

During call establishment, the call may enter an PLMN/ISDN environment, e.g., because of interworking with another 
network, with a non-PLMN/ISDN user, or with non-PLMN/lSDN equipment within the calling or called user's 
premises. When this occurs, the network may include a progress indicator information element to be included in the 
SETUP message to be sent to the called MES specifying progress description value: 

i) #1: "call is not end-to-end PLMN/ISDN; further call progress information may be available inband"; or 

ii) #3: "origination address is non-PLMN/ISDN". 
See also clause 6.5.1 for further reactions of the MES. 

6.2.2.5 Call accept 

In the MOBILE TERMINATING CALL CONFIRMED state or the CALL RECEIVED state, the call control entity in 

the MES indicates acceptance of a mobile terminating call by: 

Sending a CONNECT message to its peer entity in the network; 

- Starting Timer T313; and 

- Entering the "CONNECT REQUEST" state. 
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6.2.2.6 Active indication 

In the MOBILE TERMINATED CALL CONFIRMED state or in the CALL RECEIVED state, the call control entity of 
the network shall, upon receipt of a CONNECT message, through-connect the traffic channel (including the connection 
of an interworking function, if required), stop timers T310, T303 or T301 (if ruiming), send a CONNECT 
ACKNOWLEDGE message to its peer entity at the MES of the called user, initiate procedures to send a CONNECT 
message towards the calling user and enter the ACTIVE state. 

In the CONNECT REQUEST state, the call control entity of the MES shall, upon receipt of a CONNECT 
ACKNOWLEDGE message, stop timer T313 and enter the ACTIVE state. 

When timer T3 13 expires prior to the receipt of a CONNECT ACKNOWLEDGE message, the MES shall initiate 
clearing in accordance with clause 6.4.3. 
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Figure 6.2.6: Call acceptance and active indication at mobile terminating call establishment 

6.2.2.7 Traffic cliannel assignment at mobile terminating call establishment 

It is a network dependent decision when to initiate the assignment of a traffic channel during the mobile terminating call 
establishment phase. 

Only early assigimient as described in clause 8.3.3 is supported by the MSC. 

Initiation of the assignment phase does neither change the state of a CC entity nor affect any call control timer. 

6.2.2.8 Call queuing at mobile terminating call establishment 

The principles described in clause 6.2.1.1.10 apply accordingly. 

NOTE: The interworking to the fixed network has to fulfill the network specific requirements. 

6.2.2.9 User connection attachment during a mobile terminating call 

For speech calls: 

The MES shall attach the user coimection at latest when sending the coimect message. 
For data calls: 

The MES shall attach the user connection when receiving the CONNECT ACKNOWLEDGE message fi-om the 
network. 

6.2.3 Mobile-to-Mobile Call Establishment, Special Procedures 
6.2.3.1 Call Initiation 

To establish a mobile-to-mobile single hop connection, the following special procedures are implemented: 

• The Mobile-to-Mobile Flag is set (per 1 1.5.2.5 Channel Description IE) to a value of 1 by the network in the 
ASSIGNMENT COMMAND to the MES. 

• If the system does not support ciphering for Mobile-to-Mobile calls, then the network shall disable ciphering 
mode on the assigned channel, if previously activated, via the Cipher Mode Setting IE (11.5.2.9) in the 
ASSIGNMENT COMMAND. 
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6.2.3.2 Call Connection 

• The Call Control entity of the Terminating MES indicates acceptance of the call by sending a CONNECT 

message as defined in clause 6.2.2.5. 

• The Network responds by sending a CONNECT message to the Originating MES as defined in clause 6.2.1.6. 

• The Originating MES shall connect the call and return a CONNECT ACKNOWLEDGE message as defined in 

clause 6.2.1.6 except that the user connection shall not be attached. The MES will start a wait timer - roughly 
corresponding to the round-trip delay in the network - while waiting for a L2 acknowledge to the CONNECT 
ACKNOWLEDGE, before proceeding. 

• After the wait timer expires, the Originating MES will suspend the L2 multi-frame mode without saving any 

outstanding L3 messages which are not acknowledged. Then the MES shall initiate transmitting and 
searching for FTCB bursts as defined in GMR-2 05.002 [23], clauses 7.2.12 and 7.2.12.2. The Originating MES 
will start the M-MO timer defined in clause 11.5.2.47. 

• Upon receipt of the CONNECT ACKNOWLEDGE message fi-om the Originating MES, the network shall send 
a CONNECT ACKNOWLEDGE message to the Terminating MES. 

NOTE: The network will initiate the direct MES-to-MES coimection on the satelUte at this time. 

• Upon receipt of the CONNECT ACKNOWLEDGE message fi-om the network, the Terminating MES will wait a 
short period (e.g., 0.2 s) then initiate transmitting and searching for FTCB bursts as defined in 

GMR-2 05.002 [23], clauses 7.2.12 and 7.2.12.2. The Terminating MES will start the M-MT timer defined in 
clause 11.5.2.47. 

NOTE: The Terminating MES will send only one layer 2 CONNECT ACKNOWLEDGE to the network. 

• If the Originating MES receives the FTCB burst from the Terminating MES, then at M-MO timer expiration, it 
will resume multi-frame operation by initiating a Normal DL Establishment procedure as defined in 
GMR-2 04.006 [15], clause 8.4.1.1 using the C/R field bit setting as defined in GMR-2 04.006 [15], clause 
6.3.2.2. 

NOTE: While ttansmitting and receiving FTCBs, the MESs shall not be required to handle S-FACCH messages. 
At M-MO and/or M-MT timer expiration, the MESs shall be permitted to perform a local release of the 
call, i.e., without ttansmitting any messages over the air interface, if the frequency and time correction 
process has failed. 

• Upon receipt of the SABM, the Terminating MESs will send an acknowledge to the Originating MESs as 
defined in GMR-2 04.006 [15], clause 8.4.1.1 using the C/R field bit setting as defined in GMR-2 04.006 [15] 
clause 6.3.2.2. 

NOTE: If the Terminating MES does not receive a SABM within 5 seconds after M-MT timer expiration, then 

the terminating User Terminal will perform a local release of the call (no messages are ttansmitted by the 
MES). 

• At the end of a successful DL re-establishment, the MES shall attach the user connection. 

6.3 Signalling procedures during the "Active" state 

6.3.1 User notification procedure 

This clause does not apply to the GMR-2 system. 

6.3.2 Call rearrangements 

This clause does not apply to the GMR-2 system. 
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6.3.3 DTMF protocol control procedure 

Dual Tone Multi Frequency (DTMF) is an inband one out of four plus one out of four signalling system primarily used 
from terminal instrimients in telecommunication networks. The support of DTMF in the network is described in 
GSM 03.14 [8]. 

The MES shall be capable of transmitting DTMF messages if and only if the MES has the user connection for speech 
attached and an appropriate channel is available. 

The transaction identifier used by the DTMF messages shall be that of the attached call. 

NOTE 1: This specification means that DTMF messages can generally be sent in the ACTIVE state of a call in 

speech transmission mode or when a traffic channel is available during setup or release and the progress 
indicator IE has been received. 

NOTE 2: Since the DTMF protocol messages are sent in a store and forward mode on the signalling channels the 
control of the device at the far end may be delayed dependent on the load or quality of the channels. 

NOTE 3: The procedures described in this clause support DTMF only in the direction MES to network. 

6.3.3.1 Start DTMF request by the MES 

A user may cause a DTMF tone to be generated, e.g., by depression of a key in the MES. The relevant action is 
interpreted by the MES as a requirement for a DTMF digit to be sent in a START DTMF message on an established S- 
FACCH. This message contains the value of the digit to be transmitted (0, 1, 9, A, B, C, D, *, #). 

Only a single digit will be transferred in each START DTMF message. 

6.3.3.2 Start DTMF response by the network 

Upon receiving the START DTMF message, the network will reconvert the received digit back into a DTMF tone 
which is applied toward the remote user and returns a START DTMF ACKNOWLEDGE message to the MES. This 
acknowledgement may be used in the MES to generate an indication as a feedback for a successftil transmission. 

If the network cannot accept the START DTMF message a START DTMF REJECT message will be sent to the MES. 

6.3.3.3 Stop DTMF request by the user terminal 

When the user indicates that the DTMF sending should cease, e.g., by releasing the key, the MES will send a STOP 
DTMF message to the network. 

6.3.3.4 Stop DTMF response by the network 

Upon receiving the STOP DTMF message, the network will stop sending the DTMF tone and return a STOP DTMF 
ACKNOWLEDGE message to the MES. 

6.3.3.5 Sequencing of subsequent start DTMF requests by the MES 

The minimum length of tone generated by the network should be according to CEPT recommendation T/CS 46-02. 

The minimum gap between two subsequent tones should be according to CEPT recommendation T/CS 46-02. 

There is no defined maximum length to the tone, which will normally cease when a STOP DTMF message is received 
from the MES. However, the operator may choose to put a pre-defined time limit on the duration of tones sent. 

The appropriate sequencing of DTMF control messages is shown in figures 6.3.1 and 6.3.2. 

NOTE 1: The network shall implement the time limit option where the DTMF tone duration is controlled by the 

network irrespective of the receipt of a STOP DTMF message from the MES, but the MES shall send the 
STOP DTMF message anyway. 
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NOTE 2: The transmission time of the messages over the air interface on S-FACCH/F or S-FACCH/H (see 
GMR-2 05.002 [23]), ensures that the minimum length of tones and minimum gap between tones 
according to T/CS 46-02 are fulfilled. 
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Figure 6.3.1: Single DTIUIF transmission 
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Figure 6.3.1 : Multiple DTMF transmission 

6.3.4 Support of Dual Services 

This clause does not apply to the GMR-2 system. 

6.3.5 Mobile-to-Mobile Signaling Procedures 

During a Mobile-to-Mobile call on a single-hop connection, the following signalling channels are available. 

1) S-FACCH - User Terminal to User Terminal, and User Terminal to Network. 

2) S-SACCH - User Terminal to Network, Network to User Terminal. 

The MES shall transmit any commands/responses destined for the other User Terminal in multi-frame mode using the 
S-FACCH signalling channel. 

NOTE: The C/R bit shall be set as defined in GMR-2 04.006 [15]. 

The Network will also receive any messages transmitted by the MES using the S-FACCH signalling channel. The 
Network should ignore any message received which contains an incorrect (unexpected) C/R value. 

The MES shall transmit any commands/responses destined for the Network in unnumbered mode using the S-FACCH 
signalling channel. 

NOTE: The C/R bit shall be set as defined in GMR-2 04.006 [15]. The other User Terminal will also receive any 
messages transmitted by the MES using the S-FACCH signalling channel. The MES should ignore any 
message received which contains an incorrect (unexpected) C/R value. 
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6.4 Call clearing 

6.4.1 Terminology 

The following terms are used in the present document in the description of clearing procedures: 

A traffic channel (see GMR-2 04.003 [12]) is "connected" when the channel is part of a circuit- switched connection 
established according to the present document. 

A traffic channel is "disconnected" when the channel is no longer part of a circuit- switched connection, but is not 
yet available for use in a new connection. 

6.4.2 Exception conditions 

Under normal conditions, the call control entity of the MES, or of the network, initiates call clearing by sending a 
DISCONNECT message to its peer entity. Then both entities follow the procedures defined in clauses 6.4.3 and 6.4.4 
respectively. 

As an exception to the above rule, the call control entity of the MES, or of the network, in response to a SETUP 
message, can reject a call by stopping all running call control timers, responding with a RELEASE COMPLETE 
message, releasing the MM coimection, and returning to the NULL state, provided no other response has previously 
been sent. 

As a further exception, the call control entity of the network may initiate call clearing by stopping all running call 
control timers, sending a RELEASE message, starting timer T308, and entering the RELEASE REQUEST state. 

NOTE: This way to initiate call clearing by sending a RELEASE message should not be used by the network: 

If in-band tones/announcements are provided and the network decides to use the procedure described 
in clause 6.4.4.1; 

If the network wants to have the opportunity to respond to information sent by the MES during call 
clearing. 

If a BSSMAP CLEAR REQUEST message (see GSM 08.08 [29]) is received from the GSC, the MSG shall never send 
the DISCONNECT or RELEASE message to the MES. 

A call control entity shall accept an incoming RELEASE COMPLETE message used to initiate the call clearing even 
though the cause information element is not included. 

A control entity shall accept an incoming RELEASE message used to initiate the call clearing even though the cause 
information element is not included. 

Furthermore, a call control entity shall regard an incoming RELEASE COMPLETE message as consistent with any of 
its states. A call control entity shall regard an incoming RELEASE message as consistent with any of its states except 
the NULL state. A call control entity of the MES shall regard an incoming DISCONNECT message as consistent with 
any of its call control states except the NULL state, the RELEASE REQUEST state, and the DISCONNECT 
INDICATION state. A call control entity of the network shall regard an incoming DISCONNECT message as 
consistent with any of its call control states except the NULL state and the RELEASE REQUEST state. 

NOTE: This allows the introduction of shorter call clearing procedures in the future. 

6.4.3 Clearing initiated by the IVIES 
6.4.3.1 Initiation of call clearing 

Apart from the exceptions identified in clause 6.4.2, the call control entity of the MES shall initiate clearing by stopping 
all running call control timers, sending a DISCONNECT message, starting timer T305, and entering the DISCONNECT 
REQUEST state. 
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6.4.3.2 Receipt of a DISCONNECT message from the MES. 

The call control entity in the network in any state except the NULL state or the RELEASE REQUEST state shall, upon 
receipt of a DISCONNECT message: 

Stop all running call control timers; 

Initiate procedures to clear the network connection and the call to the remote user; 
Send a RELEASE message to its peer entity; 

- Start timer T308; 

- Enter the RELEASE REQUEST state. 

NOTE: The RELEASE message has only local significance and does not imply an acknowledgement of clearing 
from the remote user. 

6.4.3.3 Receipt of a RELEASE message from tlie network 

The call control entity of the MES in any state except the NULL state or the RELEASE REQUEST state, shall, upon 
receipt of a RELEASE message, stop all running call control timers, send a RELEASE COMPLETE message, release 
the MM connection and return to the NULL state. 

6.4.3.4 Receipt of a RELEASE COMPLETE message from tlie MES 

A call control entity of the network in any call control state shall, upon receipt of a RELEASE COMPLETE message 
from its peer entity in the MES, stop all running call control timers, release the MM connection, and return to the NULL 
state. 

6.4.3.5 Abnormal cases 

The call control entity of the MES in the DISCONNECT REQUEST state, shall, upon expiration of timer T305, send a 
RELEASE message to the network with the cause number originally contained in the DISCONNECT message, and 
optionally, a second cause information element with cause #102 "recovery on timer expiry", start timer T308, and enter 
the RELEASE REQUEST state. 

The call control entity of the network in the RELEASE REQUEST state, shall, at first expiration of timer T308, 
retransmit the RELEASE message, start timer T308, and stay in the RELEASE REQUEST state. At the second 
expiration of timer T308, the call control entity of the network shall release the MM coimection and return to the NULL 
state. 

6.4.3.6 Initiation of Call Clearing, Mobile-to-Mobile Calls 

The User Terminal (Originating User Terminal or Terminating User Terminal - the procedure is the same for either of 
them) initiates the release of a mobile-to-mobile call as described below. 

1. The Release-Initiating User Terminal transmits a CC RELEASE message with cause value #75, i.e., "MES-to- 
MES CC Release" (destined for the Other User Terminal) in an I-frame (acknowledged mode) using the S- 
FACCH and starts timer T308. 

NOTE: The network will ignore the receipt of this message. 

2. Following the I-frame, the Release-Initiating User Terminal transmits a CC RELEASE message with cause value 
#75, i.e., "MES-to-MES CC Release" (destined for the Network) in a Ul-frame (unacknowledged mode) using 
the S-FACCH. 

NOTE: The Terminating User Terminal will ignore the receipt of this message. 
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6.4.3.7 Receipt of RELEASE Message by the User Terminal 

Upon receipt of a RELEASE message with cause value #75, i.e., "MES-to-MES CC Release" in the I-frame, any of the 
User Terminals will: 

1) Transmit a RELEASE COMPLETE message with cause value #75, i.e., "MES-to-MES CC Release" to the 
Release-Initiating User Terminal. 

2) Release the MM and CC coimections and perform a local release of the RR coimection. 

6.4.3.8 Receipt of RELEASE Message by tine Network 

Upon receipt of the RELEASE message in the Ul-frame, the network will perform local release of the RR connection. 

6.4.3.9 Receipt of RELEASE COMPLETE Message by tlie User Terminal 

Upon receipt of the RELEASE COMPLETE message with cause value #75, i.e., "MES-to-MES CC Release" in the I- 
frame, the Release- Initiating User Terminal will release the MM and CC coimections and perform a local release of the 
RR connection. 

6.4.3.10 Abnormal Cases 

Upon the first timeout of timer T308, the Release-Initiating User Terminal will retransmit the CC RELEASE message 
as defined in clause 5.4.3.6, i.e., in an I-frame followed by a UI- frame. 

Timer T308 is restarted. 

Upon the second timeout of timer T308, the Release-Initiating User Terminal will release the MM and CC coimections 
and perform a local release of the RR connection. 

NOTE: If the RELEASE message is received successfully by the network on the first attempt, then the MES may 
release the call due to an S-SACCH timeout before the T308 timeout. 

6.4.4 Clearing initiated by the network 

Apart from the exception conditions identified in clause 6.4.2, the call control entity of the network shall initiate 
clearing by: sending a DISCONNECT message; and entering the DISCONNECT INDICATION state. The 
DISCONNECT message is a local invitation to clear the call. 

NOTE: When the network initiates clearing by sending a RELEASE message, the procedures described in clauses 
6.4.3.3, 6.4.3.4 and 6.4.3.5 are followed. 

6.4.4.1 Clearing when tones/announcements provided 

The network (MSC) never includes a progress indicator IE in the DISCONNECT message it sends to the MES for 
clearing the call. 

6.4.4.2 Clearing when tones/announcements not provided 

When in-band tones and announcements are not provided, the call control entity of the network shall initiate call 
clearing by stopping all running call control timers, sending a DISCONNECT message wdthout progress indicator, 
starting timer T305 and entering the "disconnect indication" state. 
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6.4.4.2.1 Receipt of a DISCONNECT message without progress indicator or witli progress 
indicator different from #8 from the network 

The call control entity of the MES, in any state except the "null" state, the "disconnect indication" state, or the "release 
request" state, shall, upon the receipt of a DISCONNECT message without progress indicator information element or 
with progress indicator different from #8: 

Stop all running call control timers. 

Send a RELEASE message; 

- Start timer T308; 

Enter the "release request" state. 

6.4.4.2.2 Receipt of a RELEASE message from the MES 

The call control entity of the network in any state except the "null" state or the "release request" state, shall, upon 
receipt of a RELEASE message, stop all running call control timers, send a RELEASE COMPLETE message, release 
the MM connection and return to the "null" state. 

6.4.4.2.3 Abnormal cases 

The call control entity of the network, having entered the "discoimect indication" state after sending a DISCONNECT 
message without progress indicator or with progress indicator different from #8, shall, upon expiration of timer T305, 
send a RELEASE message to the MES with the cause number originally contained in the DISCONNECT message, start 
timer T308, and enter the "release request" state. In addition to the original clearing cause, the RELEASE message may 
contain a second cause information element with cause #102 "recovery on timer expiry". 

6.4.4.3 Completion of clearing 

A call control entity of the MES in any call control state, shall, upon receipt of a RELEASE COMPLETE message from 
its peer entity in the network, stop all miming call control timers, release the MM coimection, and return to the "null" 
state. 

6.4.4.3.1 Abnormal cases 

The call control entity of the MES in the "release request" state, shall, at first expiration of timer T308, retransmit the 
RELEASE message and restart timer T308. At second expiration of timer T308, the call control entity of the MES shall 
release the MM cormection and return to the "nuU" state. 

6.4.5 Clear collision 

Clear collision occurs when both the MES and the network simultaneously transfer DISCONNECT messages 
specifying the same call. 

The behaviour of the network call control entity receiving a DISCONNECT message while in the "disconnect 
indication" state is specified in clause 6.4.3. The behaviour of the MES call control entity receiving a DISCONNECT 
message while in the "disconnect request" state is defined in clause 6.4.4. 

Clear collision can also occur when both sides simultaneously transfer RELEASE messages related to the same call. 
The entity receiving such a RELEASE message while within the "release request" state shall stop timer T308, release 
the MM coimection and enter the "nuU" state (without sending a RELEASE COMPLETE message). 
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6.5 Miscellaneous procedures 

6.5.1 In-Band tones and announcements 

When the network wants to make the MES attach the user connection (e.g., in order to provide in-band 
tones/announcement) before the MES has reached the "active" state of a call, the network may include a progress 
indicator IE indicating user attachment in a suitable CC message: 

In the case of the originating call when in-band tones or an announcement is generated by the remote party: 
according to the information provided in the Address Complete Message (ISUP {ACM} message) from the remote 
party, the MSC includes a progress indicator IE in the ALERTING message, or it will send a PROGRESS message. 

In the case of emergency calls: if an announcement is to be provided before establishing the call, the PROGRESS 
message containing the progress indicator IE indicating "user attachment," is sent to the MES before providing the 
announcement on the traffic channel. 

A progress indicator IE indicates user attachment if it specifies a progress description in the set (1, 2, 3) or in the set (6, 
7, 8, 20). 

On reception of a SETUP, CALL PROCEEDING, ALERTING, CONNECT, or PROGRESS message, the MES shall 
proceed as specified elsewhere in clause 6. In addition, if the progress indicator IE indicated user attachment and a 
speech mode traffic channel is appropriate for the call, the MES shall attach the user coimection for speech as soon as 
an appropriate channel in speech mode is available. (If a new order to attach the user connection is received before the 
attachment has been performed, the new order shall supersede the previous one.) 

NOTE: This allows the use of progress indicator lEs independently from the channel modes appropriate for the 
call. 

6.5.2 Call collisions 

Call collisions as such cannot occur at the Network. Any simultaneous mobile originating or mobile terminating calls 
are dealt with separately assigned and different transaction identifiers. 

6.5.3 Status procedures 
6.5.3.1 Status enquiry procedure 

Whenever a call control entity wishes to check the call state of its peer entity, it may initiate the status enquiry 
procedure. 

NOTE: This may, in particular, apply to procedural error conditions described in clause 8. 
The MSC shall trigger the status enquiry procedure only after a switchover. 

A call control entity initiates the status enquiry procedure by sending the STATUS ENQUIRY message and starting 
timer T322. While timer T322 is running, the call control entity shall not send further STATUS ENQUIRY messages. 

Upon receipt of a STATUS ENQUIRY message, the receiver shall respond with a STATUS message, reporting the 
current call state and cause value #30 "response to STATUS ENQUIRY". Receipt of the STATUS ENQUIRY shall not 
result in a state change relating to any protocol and connection of the receiver. 

If a STATUS message is received that contains cause value #30 "response to STATUS ENQUIRY", timer T322 shall 
be stopped and further appropriate actions taken based on the information in that STATUS message relative to the 
current state of the receiver of the STATUS message. These further "appropriate actions" are implementation 
dependent. However, the actions prescribed in clause 6.5.3.2 shall apply. 

If a clearing message is received while timer T322 is ruiming, timer T322 shall be stopped, and call clearing shall 
continue. 

If T322 expires, the STATUS ENQUIRY message shall not be transmitted and the clearing of the call shall be initiated 
by the MSC sending a {Clear Command} BSSMAP message to the GSC. 
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Possible states sent by the network to the MES in response to a status enquiry procedure are NO, NO.l, Nl, N3, N4, N6, 
N7, N8, N9, NIO (possibly together with the auxihary state), N12, N19 and N28. 

6.5.3.2 Reception of a STATUS message by a CC entity 

6.5.3.2.1 STATUS message with incompatible state 

On receipt of a STATUS message reporting an incompatible call control state, the receiving entity shall clear the call by 
sending a RELEASE COMPLETE message with cause # 101 "message not compatible with protocol state". The 
reported call control state is incompatible if the combination of call control states at the sender and receiver side cannot 
occur, do not match, or cannot be aligned by actions of the receiver. The exact definition is implementation dependent. 

On receipt of the MES state U12, U19 or UO in a STATUS message in answer to a status enquiry procedure, the 
network shall consider the call transaction as released at the MES level and will complete the call clearing at the 
network level (including the trigging of the radio resource release). 

On receipt of a STATUS message expected in response to a status enquiry procedure, if the MES state is different from 
U4, U7, U8 or UIO, or if the cause indicated in the STATUS message is other that {#30 response to status enquiry}, the 
network shall release the call (including the sending of the release procedure with the MES, i.e., sending a 
DISCONNECT message). 

On receipt of a spontaneous STATUS message (i.e., not answering a status enquiry procedure), the state received from 
the MES shall be regarded as incompatible if its combination with the network call control state cannot occur or do not 
match. In that case the call shall be released (including the sending of the release procedure with the User Terminal, i.e., 
sending a DISCONNECT message). 

6.5.3.2.2 STATUS message with compatible state 

On receipt of the MES states, U7, U8 or UIO (for a terminating call) or, U4 or UIO (for an originating call) in a 
STATUS message in answer to a status enquiry procedure, the network state shall be updated according to the MES 
state. Auxiliary states that can be received together with the MES state UIO may not be taken into account by the 
network. 

On receipt of a spontaneous STATUS message (i.e., not answering a status enquiry procedure), if the state received 
from the MES shall be regarded as compatible, no action shall be performed by the network. A STATUS message may 
be received indicating a compatible call state but containing one of the following causes: 

#95 " semantically incorrect message" ; 

# 96 "invalid mandatory information"; 

# 97 "message type non-existent or not implemented"; 

# 98 "message type not compatible with protocol state"; 

# 99 "information element non-existent or not implemented"; 

# 100 "invalid information element contents. 

This indicates that the transmitter of the STATUS message was unable to accept some information sent by the recipient 
of the STATUS message. This allow the recipient to retransmit some or all of the information. Other actions are 
possible and are implementation dependent. They may include releasing the call. 

The cause values hsted above may lead the receiving entity to discard the STATUS message (refer also to clause 9 on 
Error Handling). 

6.5.4 Call re-establishment, MES side 

This clause does not apply to the GMR-2 system. 
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6.5.5 Call re-establishment, network side 

This clause does not apply to the GMR-2 system. 

6.5.6 Progress 

The MSC may send a PROGRESS message to the MES when the {Address Complete Message) (ISUP ACM) indicates 
that further call progress information may be available in-band. The ISUP {Progress} message is ignored by the MSC. 

The MSC sends a PROGRESS message to the MES when an announcement is to be generated before the call is 

established. 

On receipt of a PROGRESS message during the establishment or release of a call, the MES shall stop all call control 
timers related to that call. 

NOTE: If the PROGRESS has been received before the receipt of a CALL PROCEEDING message, the MES 
will not start timer T310 on receipt of a CALL PROCEEDING message, see clause 6.2.1.1.3. 
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Figure 6.5.1 : Progress 



7 Support of packet services 

The circuit-switched call control procedures of clause 6 apply to this case. 



8 Examples of structured procedures 
8.1 General 

Clause 8 contains examples of how the network may group together the elementary procedures (i.e., the procedures 
defined in clauses 4 through 6) in order to provide normal service. 

The layer 3 signalling at the radio interface may be divided into so-called structured procedures which consist of 
specific combinations of elementary procedures. In clause 8.3, selected examples of structured procedures are 
described. A structured procedure consists of (not necessarily all) components shown in figure 8.1.1. These components 
are characterized by the purpose of their use in structured procedures and their message flow in the following clauses 
8.1.1 through 8.1.7. 
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Paging Request 
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RR Connection 
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RR Connection 
Release 



Figure 8.1.1: Components of structured procedures 

8.1.1 Paging request 

The paging procedure is used to locate a MES to which a connection shall be established. 

Upon receipt of a PAGING REQUEST message, the addressed MES initiates the immediate assigimient procedure. 
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Figure 8.1.2: Paging request 

8.1.2 Immediate assignment 

The immediate assignment procedure is always initiated by the MES. It may be triggered by a paging request or by a 
mobile originating service request. 

The MES sends a CHANNEL REQUEST message on the Random Access Channel. The network responds with an 
IMMEDIATE ASSIGNMENT message that causes the MES to seize the indicated dedicated channel. 
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Figure 8.1.3: Immediate assignment 
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8.1.3 Service request and contention resolution 

The initial service request message (a PAGING RESPONSE, LOCATION UPDATING REQUEST, CM SERVICE 
REQUEST) is sent by the MES to the network piggy-backed in the L2 SABM frames establishing the main signalling 
link. Its purpose is: 

To provide non-confidential information relevant to the service requested for the RR and MM sublayer in the 
network; 

To allow for contention resolution. 

Contention resolution provides a resolution process when more than one MES try to seize a channel allocated during the 
immediate assignment procedure (because they happened to use the same random reference at the same time during 
random access). This is achieved by the network including in a L2 UA frame the same information field as that one 
received in the L2 SABM frame to which the UA frame responds. By comparing the two information fields, the MES 
can verify whether it was the originator of the L2 establishment because the service request contains the mobile identity. 
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Figure 8.1.4: Service request and contention resolution 

8.1.4 Authentication 

The purpose of authentication is to validate the identity provided by the MES. It is initiated by the network. The 
authentication procedure also provides the MES with information from which a new ciphering key can be derived. The 
network decides whether or not to use authentication. This may depend on the context. 
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Figure 8.1.5: Service request and contention resolution 



8.1 .5 Cipliering mode setting 

Ciphering mode setting is initiated by the network. Its purpose is to insttuct the MES whether or not to use ciphering 
and which algorithm to use. 

Where ciphering is used, this procedure synchronizes the start of ciphering at the MES and in the network. 
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Figure 8.1.6: Ciphering mode setting 



8.1.6 Transaction pliase 

A variety of elementary procedures described in clauses 4 through 6 may be performed during the ttansaction phase. In 
this clause, only the ttansmission mode change procedure is characterized. 
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8.1 .6.1 Transmission mode cliange 

The transmission mode change procedure may be used when a traffic channel has been assigned: 

During the in-call modification procedure in order that the channel mode of the S-TCH be changed to that one 
requested by call control; 

During call establishment with very early assignment in order that the channel mode of the S-TCH be changed 
from signalling only to the mode requested by call control; 

During the active phase of a data call in order that the speed of the data transmission be changed. 

The transmission mode procedure is initiated by the network sending a CHANNEL MODE MODIFY message and 
completed by the MES changing the mode of the S-TCH and sending back a CHANNEL MODE MODIFY 
ACKNOWLEDGE message. 
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Figure 8.1.7: Channel mode change 

8.1.7 Channel release 

Once the transaction phase has been completed, the channel is released by the channel release procedure. The data link 
layer is released explicitly as described in GMR-2 04.006 [15]. After the channel release is completed, the radio 
resources which were in use may be reallocated by the network. 
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Figure 8.1.8: Channel release 
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8.2 



Abnormal cases 



Abnormal cases are not described in the examples of clause 8. They may arise from: 



a) 



Failure at a lower layer (e.g., loss of radio connection); 



b) 



Failure of an elementary procedure; 



c) 



Errors in an elementary procedure. 



8.3 



Selected examples 



The following examples are considered: 

• Location updating; 

• Mobile originating call establishment, without OACSU (early assignment); 

• Mobile terminating call establishment, without OACSU (early assignment); 

• Call clearing: 

- i) Network initiated; 

- ii) Mobile initiated; 

- iii) MES to MES call clearing; 

• DTMF protocol control; 

• In-call modification. 



The location updating procedure is always initiated by the MES, e.g., when it iinds itself in a different location area 
from the one in which it was registered before. The cases where the procedure is triggered are described in clause 5 of 
the present document and in GMR-2 03.022 [10]. 

The procedure is shown in figure 8.3.1. 

The MES initiates immediate assigimient, service request using the LOCATION UPDATING REQUEST message, and 
contention resolution. 

The network requires authentication (this again is an option). 

After sending of the LOCATION UPDATING ACCEPT message the network initiates the channel release if no further 
transactions are scheduled. 
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Figure 8.3.1: Location updating: Successful case 

8.3.2 Mobile originating call establishment 

The MES initiates immediate assignment, service request using the CM SERVICE REQUEST message, and contention 
resolution. The network may initiate authentication and may start the ciphering mode setting. 

After sending the CIPHERING MODE COMPLETE message, the MES initiates call establishment by sending the 
SETUP message to the network. The network answers with a CALL PROCEEDING message: 

Non-OACSU option (early assigimient): 

With this option the network allocates a traffic channel to the MES before it initiates call establishment in the fixed 
network. 

If call queuing is applied, it may cause variable delay in the traffic channel assigimient. 

When user alerting has been initiated at the called side, an ALERTING message is sent to the MES. The network may 
optionally instruct the MES to attach the user connection at this stage of the call by means of the progress indicator 
information element set to the value #1 or #8 (if the ringing tone will be sent by the remote end) in the ALERTING 
message. In that case, an alerting ringing tone has to be generated by the network. 

NOTE: The speech codec is transparent for supervisory tones. 

A CONNECT message and its acknowledgement CONNECT ACKNOWLEDGE complete the call establishment 
when the called party has answered. 



The mobile originating call setup with early assigimient is shown in figure 8.3.2. 
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Figure 8.3.2: Mobile originating caii estabiishment withiout OACSU (early assignment) 

8.3.3 Mobile terminating call establishment 

Non-OACSU option (early assignment) : 

With this option the network initiates the assignment of a traffic channel upon receiving the CALL CONFIRMED 

message. 



The signal IE is not included in the SETUP message. Therefore, user alerting is initiated only after a traffic channel has 
been allocated. An ALERTING message will be sent to the network. 
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NOTE: If the called MES is already involved in an active call and if the SETUP message is to be sent to same 
subscriber for a call waiting or for operator intervention, the signal IE will be included in that SETUP 
message. If that active call is a MES-to-MES single hop call, that SETUP message for call waiting or 
operator intervention shall be stopped at the GSC in order not to be sent to the MES: 

In the case of a call waiting, the MSC shall not receive any response to the SETUP message from the 
GSC and the waiting call shall be released toward the calling party at T303 timer expiration; 

In the case of an operator intervention, the MSC shall receive a RELEASE COMPLETE message 
from the GSC with cause #88 "incompatible destination" to indicate that operator intervention is not 
possible and the operator call to be released. 

When the called user answers, the MES sends a CONNECT message to the network. Upon receiving the 
CONNECT message, the network completes the through cormection of the communication path and sends a 
CONNECT ACK message to the MES. 



MES 



Network 
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IMMEDIATE ASSIGNMENT 
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CM SERVICE REQUEST 

> 

AUTHENTICATION REQUEST 

< 

AUTHENTICATION RESPONSE 

> 

CIPHER MODE COMMAND 

< 

CIPHER MODE COMPLETE 

> 

SETUP 

> 

CALL PROCEEDING 

< 

ASSIGNMENT COMMAND 

< 

ASSIGNMENT COMPLETE 

- — > 

ALERTING 

<— 

CONNECT 

< 

CONNECT ACKNOWLEDGE 

> 
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Service Request 
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Ciphering Mode Setting 



Call Initiation 



Assignment of a traffic 
channel 



User Alerting 
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Figure 8.3.3: Mobile terminating caii estabiishment without OACSU (eariy assignment) 
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8.3.4 Call clearing 

a) Initiated by the network: 

The network initiates the clearing of a call by sending a DISCONNECT message to the MES (see also clause 
6.4.4). 

Upon receiving the DISCONNECT message from the network, the MES sends a RELEASE message to the 
network. 

Upon receiving the RELEASE message from the MES, the network sends a RELEASE COMPLETE to the MES 
and, if the traffic channel is longer needed (e.g., last activity on the traffic channel), performs the channel release 
procedure as described in clause 8.1.7. 

Upon receiving the RELEASE COMPLETE message, and if the cleared call was the last activity on the traffic 
channel, the MES waits for the release of the channel which is always initiated by the network. 

Call clearing initiated by the network is shown in figure 8.3.4.1. 

b) Initiated by the MES in a PSTN call: 

The MES initiates the clearing of a call by sending a DISCONNECT message to the network (see also clause 
6.4.3). 

Upon receiving the DISCONNECT message from the MES, the network sends a RELEASE message to the 
MES. 

Upon receiving the RELEASE message from the network, the MES sends a RELEASE COMPLETE to the 
network, which, if the traffic channel is no longer needed (e.g., last activity on the traffic channel), performs the 
channel release procedure as described in clause 8.1.6. 

Call clearing initiated by the MES is shown in figure 8.3.4.2. 

c) Initiated by the MES in a MES-to-MES call (single hop): 

A MES initiates the clearing of a call by sending a RELEASE message to the other MES. 

Upon receiving the RELEASE message from the first MES, the second MES sends a RELEASE COMPLETE 
message to the first MES. 

The RELEASE COMPLETE message is received by the GSC and the GSC will send then 
NCC_DISCONNECT_SAT_CMD to the NCC to close the satelhte link. The GSC on receipt of the 
NCC_DISCONNECT_SAT_CMD_ack command to inform it that this option has completed, will clear both the 
MES calls with the MSC by the CLEAR REQUEST/COMMAND and COMPLETE sequence. 

d) An abnormal mobile to mobile call (double hop): 

If a MES initiates the clearing of a call by sending a RELEASE message to the other MES and receives a RR 
Release instruction from the network, the mobile shall instigate the call clearing procedure defined in the RR 
Release procedure. 

If a MES receives a RR Release instruction from the network, the mobile shall instigate the call clearing 
procedure defined in the RR Release procedure. 
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Figure 8.3.4.1 : Call clearing Initiated by the network 
MES Network 
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Figure 8.3.4.2: Call clearing initiated by the iUIES 
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8.3.5 DTMF protocol control 

Figure 8.3.5 shows the structured procedure for DTMF protocol control. 

MES Network 



Active Call 



START DTMF 

> 

START DTMF 
ACKNOWLEDGEMENT 

< 

STOP DTMF 

> 

STOP DTMF ACKNOWLEDGEMENT 

< 



DTMF Generation 
Started 



DTMF Generation 
Stopped 



Active Call 



Figure 8.3.5: DTMF protocol control 



8.3.6 Handover 

This clause does not apply to the GMR-2 system. 

8.3.7 In-call modification 

Figure 8.3.6 shows the structured procedure for in-call modification. 
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Network 



Active Call 



MODIFY 



In-call modification e.g. 
from Speech to Data 



Transmission mode 
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MODIFY COMPLETE 
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Active Call 



Figure 8.3.6: In-Call modification 
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9 



Handling of unknown, unforeseen and erroneous 
protocol data 



9.1 



General 



The procedures specified in the present document and call-related supplementary service handling in GSM 04.10 [17] 
apply to those messages which pass the checks described in this clause. 

This clause also specifies procedures for the handling of unknown, unforeseen, and erroneous protocol data by the 
receiving entity. These procedures are called "error handling procedures," but in addition to providing recovery 
mechanisms for error situations, they define a compatibility mechanism for future extensions of the protocols. 

Error handling concerning the value part of the Facihty IE and of the SS Version Indicator IE are not in the scope of the 
present document. It is defined in GSM 04.10 [17] and the GSM 04.8x series. 

Due to implementation within the MSG, clauses 9.1 to 9.8 may not be appUed in order of precedence. 

(The strategy of the network is to limit as much as possible the actions performed on reception of faulty messages in 
order to improve the overall performance.) 

Most error handling procedures are mandatory for the MES. 

Detailed error handling procedures in the network are implementation dependent and may vary. However, when 
extensions of this protocol are developed, networks will be assumed to have the error handling that is indicated in this 
clause as mandatory ("shall") and that is indicated as strongly recommended ("should"). Clauses 9.2, 9.3, 9.4, 9.5 and 
9.7.2 do not apply to the error handling in the network applied to the receipt of initial layer 3 message. If the network 
diagnoses an error described in one of these clauses in the initial Layer 3 message received from the MES, it shall 



Try to recognize the classmark and then take further implementation dependent actions; or 
Release the RR-connection. 

Also, the error handling of the network is only considered as mandatory or strongly recommended when certain 
thresholds for errors are not reached during a dedicated connection. 

In this clause the following terminology is used: 

An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved" in 
clause 11 , or if its value part violates rules of clause 1 1 . However, it is not a syntactical error that a type 4 IE 
specifies in its length indicator a greater length than defined in clause 11. 

A message is defined to have semantically incorrect contents if it contains information which, possibly dependent 
on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part (i.e., 
clauses 4, 5 and 6) of the present document, GSM 04.10 [17], or the relevant GSM 04.8x series. 



either: 
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9.2 Message too short 

When a message is received that is too short to contain a complete message type information element, that message 
shall be ignored (see GMR-2 04.007 [16]). 

9.3 Unknown or unforeseen transaction identifier 

If transaction identifier (TI) checks are processed at the application level, which is the case in the MSG, then the 
following message faults will be found before a transaction identifier failure: 

a) Unknown or unforeseen message type; 

b) Non-semanticaUy mandatory information element errors; 

c) Unknown and unforeseen lEs in the non imperative message part; 

d) Syntactically incorrect optional lEs. 

The MES and network shall ignore a call control message received with TI value "111". For a call control message 
received with TI different from "111", the following procedures shall apply: 

i) Whenever any call conttol message except EMERGENGY SETUP, SETUP or RELEASE GOMPLETE is 
received specifying a transaction identifier which is not recognized as relating to an active call or to a call in 
progress, the receiving entity shall send a RELEASE GOMPLETE message with cause #81 "invalid transaction 
identifier value" using the received transaction identifier value and remain in the "nuU" state; 

ii) Whenever a RELEASE GOMPLETE message is received specifying a ttansaction identifier which is not 
recognized as relating to an active call or to a call in progress, the message may be ignored; 

iii) Whenever an EMERGENGY SETUP message or a SETUP message is received specifying a transaction 
identifier which is not recognized as relating to an active call or to a call in progress, and with a ttansaction 
identifier flag incorrectly set to "1", the message shall be ignored; 

iv) When a SETUP message is received by the MES specifying a ttansaction identifier which is recognized as 
relating to an active call or to a call in progress, this SETUP message shall be ignored; 

v) When an EMERGENGY SETUP message or a SETUP message is received by the network specifying a 
ttansaction identifier which is recognized as relating to an active call or to a call in progress, this message need 
not be tteated and the network may perform other actions. 

Before allocating or accepting a new transaction identifier, the number of already existing ttansactions for the network, 
whether they are related to an incoming or outgoing operation, shall be checked. If this number is less than 8, then the 
ttansaction is accepted, otherwise the message shall be rejected. 

9.4 Unknown or unforeseen message type 

If the MES receives a message with message type not defined for the PD, or not implemented by the receiver, it shall 
ignore the message except for the fact that, if an RR connection exists, it shall return a status message (STATUS, RR 
STATUS or MM STATUS depending on the protocol discriminator) with cause # 97 "message type non-existent or not 
implemented". 

If the network receives an RR message or MM message with message type not defined for the PD, or not implemented 
by the receiver in a protocol state where reception of an unsolicited message with the given PD from the MES is not 
foreseen in the protocol, the network actions are implementation dependent. Otherwise, if the network receives a 
message with message type not defined for the PD or not implemented by the receiver, it shall ignore the message. 

NOTE: A message type not defined for the PD in the given direction is regarded by the receiver as a message 
type not defined for the PD, see GMR-2 04.007 [16]. 

If the MES receives a message not compatible with the protocol state, the MES shall ignore the message except for the 
fact that, if an RR connection exists, it returns a status message (STATUS, RR STATUS or MM STATUS depending 
on the protocol discriminator) with cause #98 "Message type not compatible with protocol state". 
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If bit 8 of the message type IE is set ("1"), it is treated as "not defined." The message is ignored. 

If the network receives a message not compatible with the protocol state, the message is ignored. 

If compatibility check of message type with protocol state is processed at appUcation level, the following mistakes will 
be discovered before those compatibility mistakes (if any): 

a) Non semantical mandatory information element errors; 

b) Unknown and unforeseen lEs in the non imperative part; 

c) Syntactically incorrect optional lEs. 



9.5 Non-semantical mandatory information element errors 



When on receipt of a message: 

An "imperative message part" error; or 

A "missing mandatory IE" error is diagnosed, or when a message containing: 
A syntactically incorrect mandatory IE; 

An IE unknown in the message, but encoded as "comprehension required" (see clause 1 1.5); or 
An out of sequence IE encoded as "comprehension required" (see clause 1 1.5) 
is received. 

The MES shall proceed as follows: 

When the message is not one of the messages listed in clauses 9.5.1, 9.5.2, and 9.5.3, the MES shall ignore the 
message except for the fact that, if an RR connection exists, it shall return a status message (STATUS, RR STATUS 
or MM STATUS depending on the protocol discriminator) with cause # 96 "invalid mandatory information". 

The network shall proceed as follows: 

When the message is not one of the message Usted in clause 9.5.3 b) or c), the network shall either: 

- Try to treat the message (the exact further actions are implementation dependent), or 

- Ignore the message except that it should return a status message (STATUS, RR STATUS or MM STATUS 
depending on the protocol discriminator) with cause # 96 "invalid mandatory information". 

Imperative message part errors include format errors, i.e., an IE with a length outside the range given by the present 
document. 



For the MES, the following procedures shall apply: 

If the message is a CHANNEL RELEASE message, the actions taken shall be the same as specified in clause 4.5 
"RR connection release". 



9.5.1 



Radio resource management 



9.5.2 



IVIobility management 



No exceptional cases are described for mobility management messages. 
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9.5.3 Call control 

a) Messages other than DISCONNECT and RELEASE COMPLETE are ignored and no status message is sent. 

b) If the message is a DISCONNECT message, a RELEASE message shall be returned with cause value # 96 "invaUd 
mandatory information" and clause 6.4 "call clearing" applies as normal. 

c) If the message is a RELEASE COMPLETE message, it shall be treated as a normal RELEASE COMPLETE 
message. 

9.6 Unknown and unforeseen lEs in the non-imperative 
message part 

9.6.1 lEIs unknown in the message 

The MES shall ignore all lEs unknown in a message which are not encoded as "comprehension required". 

The network shall ignore all lEs unknown in a message which are not encoded as "comprehension required". 

In order to continue decoding, the length of the unknown IE is deduces from the value of bit 8 of the lEI. The format is 
TV with a length of 1 byte if value is 1. Otherwise, the format shall be TLV. 

9.6.2 Out of sequence lEs 

The MES shall ignore all out of sequence IBs in a message which are not encoded as "comprehension required". 
The network shall ignore all out of sequence lEs in a message which are not encoded as "comprehension required". 

9.6.3 Repeated IBs 

If an information element with format T, TV, or TLV is repeated in a message in which repetition of the information 
element is not specified in clause 10 of the present document, only the contents of the information element appearing 
first shall be handled and all subsequent repetitions of the information element shall be ignored. When repetition of 
information elements is specified, only the contents of specified repeated information elements shall be handled. If the 
limit on repetition of information elements is exceeded, the contents of information elements appearing first up to the 
limit of repetitions shall be handled and all subsequent repetitions of the information element shall be ignored. 

9.7 Non-imperative message part errors 

This category includes: 

Syntactically incorrect optional lEs; 
Conditional IE errors. 
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9.7.1 



Syntactically incorrect optional lEs 



The MES shall treat aU optional lEs that are syntactically incorrect in a message as not present in the message. 
The network shall treat aU optional lEs that are syntactically incorrect in a message as not present in the message. 



When the MES, upon receipt of a message, diagnoses a "missing conditional IE" error or an "unexpected conditional 
IE" error or when it receives a message containing at least one syntactically incorrect conditional IE, it shall ignore the 
message except for the fact that, if an RR connection exists, it shall return a status message (STATUS, RR STATUS, or 
MM STATUS depending on the PD) with cause value # 100 "conditional IE error". 

When the network receives a message and diagnose a "missing conditional IE" error or an "unexpected conditional IE" 
error or when it receives a message containing at least one syntactically incorrect conditional IE, the network shall 
either: 

Try to treat the message (the exact further actions are implementation dependent); 
Ignore the message. 



When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of the 
present document (i.e., clauses 4, 5, and 6) are performed. If however, no such reactions are specified, the MES shall 
ignore the message except for the fact that, if an RR connection exists, it returns a status message (STATUS, RR 
STATUS, or MM STATUS depending on the PD) with cause value # 95 "semantically incorrect message." 

The network should follow the same procedure except that a status message is not normally transmitted. 

Semantic checking of the Facility information element value part (defined in GSM 04.80 [19]) is the subject of the 
technical specifications GSM 04.10 [17] and the GSM 04.8x series. 

NOTE: Two cases of semantically incorrect IE contact may happen: 



Semantic error in a checked parameter: 

This type of error usually leads to an application error (e.g., error message sent back). No STATUS 
message is sent. 

Semantic error in a unchecked parameter: 

This type of error is not detected at least immediately. If the corresponding parameter is used at a 
later stage in the processing, an error wiU then occur. If the parameter is not used, then the error is 
not detected. 



9.7.2 



Conditional IE errors 



9.8 



IVIessages with semantically incorrect contents 
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1 Message functional definitions and contents 

This clause defines the structure of the messages of those Layer 3 protocols defined in the present document. These are 
standard L3 messages as defined in GMR-2 04.007 [16], with the exception of those sent on the S-SCH and S-RACH. 

Each definition given in the present clause includes; 

a) A brief description of the message direction and use, including whether the message has: 

1) Local significance, i.e., relevant only on the originating or terminating access; 

2) Access significance, i.e., relevant in the originating and terminating access, but not in the network; 

3) Dual significance, i.e., relevant in either the originating or terminating access and in the network; or 

4) Global significance, i.e., relevant in the originating and terminating access and in the network. 

b) A table listing the information elements permitted to be in that message and their order of their appearance in the 
message. All information elements that may be repeated are explicitly indicated (V and LV formatted lEs, which 
compose the imperative part of the message, occur before T, TV, and TLV formatted IBs which compose the 
non-imperative part of the message, see GMR-2 04.007 [16]). In a (maximal) sequence of consecutive 
information elements with half octet length, the first information element with half octet length occupies bits 1 to 
4 of octet N, the second bits 5 to 8 of octet N, the third bits 1 to 4 of octet N +1 etc. Such a sequence always has 
an even number of elements. 

For each information element, the table indicates: 

1) The information element identifier (lEl), in hexadecimal notation, if the IE has format T, TV, or TLV. 
Usually, there is a default lEl for an information element type. Default lEls of different IE types of the same 
protocol are different. If the lEl has half octet length, it is specified by a notation representing the lEI as a 
hexadecimal digit followed by a "-" (example: B-); 

2) The name of the information element (which may give an idea of the semantics of the element). The name of 
the information element (usually written in itaUcs) followed by "IE" or "information element" is used in this 
technical specification as reference to the information element within a message; 

3) The name of the type of the information element (which indicates the coding of the value part of the IE), and 
generally, the referenced clause of clause 10 of the present document describing the value part of the 
information element; 

4) The presence requirement indication (M, C. or 0) for the IE as defined in GMR-2 04.007 [16]; 

5) The format of the information element (T, V, TV, LV, TLV) as defined in GMR-2 04.007 [16]; 

6) The length of the information element (or permissible range of lengths), in octets, in the message, where "?" 
means that the maximum length of the IE is only constrained by link layer protocol, and in the case of the 
Facility IE by possible further conditions specified in GSM 04.10 [17]. This indication is informative. 

c) Clauses specifying, where appropriate, conditions for lEs with presence requirement C or in the relevant 
message which together with other conditions specified in the present document define when the information 
elements shall be included or not, what non-presence of such lEs means, and, for lEs with presence requirement 
C, the static conditions for presence and/or non-presence of the lEs (see GMR-2 04.007 [16]). 
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10.1 Messages for radio resources management 

Table 10.1.1 summarizes the messages for Radio Resources management. 



Table 10.1.1: Messages for Radio Resource Management 



Channel Establishment Messages 


Reference 


IMMEDIATE ASSIGNMENT 
IMMEDIATE ASSIGNMENT REJECT 


10.1.18 
10.1.20 


Ciphering Messages: 


Reference 


CIPHERING MODE COMMAND 
CIPHERING MODE COMPLETE 


10.1.9 
10.1.10 


Handover Messages 


Reference 


ASSIGNMENT COMMAND 
ASSIGNMENT COMPLETE 
ASSIGNMENT FAILURE 


10.1.2 
10.1.3 
10.1.4 


Channel Release Messages: 


Reference 


CHANNEL RELEASE 


10.1.7 


Paging Messages: 


Reference 


Paging Request-HPACH IMSI 
PAGING REQUEST TYPE 1 
PAGING RESPONSE 


10.1.45 
10.1.22 
10.1.25 


System Information Messages: 


Reference 


SYSTEM INFORMATION TYPE 2 
SYSTEM INFORMATION TYPE 3 
SYSTEM INFORMATION TYPE 6 
SYSTEM INFORMATION TYPE 7 
SYSTEM INFORMATION TYPE 8 
SYSTEM INFORMATION TYPE 9 
SYSTEM INFORMATION TYPE 10 
H-BCCH Version Number 


10.1.32 
10.1.34 
10.1.40 
10.1.41 
10.1.42 
10.1.43 
10.1.44 
10.1.48 


Miscellaneous Messages: 


Reference 


CHANNEL MODE MODIFY 

CHANNEL MODE MODIFY ACKNOWLEDGE 

CHANNEL REQUEST 

CLASSMARK CHANGE 

CLASSMARK ENQUIRY 

MEASUREMENT REPORT 

SYNCHRONIZATION CHANNEL INFORMATION 

RR STATUS 

TRANSMIT DISABLE 

TRANSMIT DISABLE ACK 


10.1.5 
10.1.6 
10.1.8 
10.1.11 
10.1.12 
10.1.21 
10.1.30 
10.1.29 
10.1.46 
10.1.47 
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10.1.1 Additional assignment 

This clause does not apply to the GMR-2 system. 

10.1.2 Assignment command 

This message is sent on the main S-DCCH by the Network to the MES to change the channel configuration to another 
independent dedicated channel configuration, when no timing adjustment is needed (see table 10.1.2.1). 

Message Type: ASSIGNMENT COMMAND 

Significance: Dual 

Direction: Network to MES 



Table 10.1.2.1 : ASSIGNMENT COMMAND message content 



lEI 


Informatlon Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Assignment Command Message 

Type 


Message Type 


11.4 


M 


V 


1 




Description of tlie Channel 


Channel Description 


11.5.2.5 


M 


V 


4 




Forward Epoch Delay 


Forward Epoch 
Delay 


11.5.2.46 


M 


V 


2 




Power Command 


Power Command 


11.5.2.28 


M 


V 


1 


63 


Mode of the Channel 


Channel Mode 


11.5.2.6 





TV 


2 


9- 


Cipher Mode Setting 


Cipher Mode Setting 


11.5.2.9 





TV 


1 



10.1.2.1 Mode of the channel 

If this information element is not present, the channel mode of the previously allocated channel is assumed. 

1 0.1 .2.2 Description of the Second Channel 

This clause does not apply to the GMR-2 system. 

10.1.2.3 Mode of the Second Channel 

This clause does not apply to the GMR-2 system. 

1 0.1 .2.4 Mobile Allocation and Frequency List, after the starting time 

This clause does not apply to the GMR-2 system. 

10.1.2.5 Starting Time 

This clause does not apply to the GMR-2 system. 

1 0.1 .2.6 Reference cell frequency list 

This clause does not apply to the GMR-2 system. 

10.1.2.7 Cell Channel Description 

This clause does not apply to the GMR-2 system. 
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1 0.1 .2.8 Cipher mode setting 

This information element appears when the ciphering mode is changed after the MES has switched to the assigned 
channel. 

If this information element is omitted, the mode of ciphering is not changed after the MES has switched to the assigned 
channel. 

10.1.3 Assignment complete 

This message is sent on the main S-DCCH from the MES to the Network to indicate that the MES has established the 
main signalling link successfully (see table 10.1.3.1). 

Message Type: ASSIGNMENT COMPLETE 

Significance: Dual 

Direction: MES to Network 



Table 10.1.3.1: ASSIGNMENT COMPLETE message content 



lEI 


information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




ASSIGNMENT COMPLETE 
Message Type 


Message Type 


11.4 


M 


V 


1 




RR Cause 


RR Cause 


11.5.2.31 


M 


V 


1 



10.1.4 Assignment failure 

This message is sent on the main S-DCCH on the old charmel from the MES to the network to indicate that the MES 
has failed to seize the new channel (see table 10.1.4.1). 

Message Type: ASSIGNMENT FAILURE 

Significance: Dual 

Direction: MES to network 



Table 10.1.4.1 : ASSIGNMENT FAILURE message content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




ASSIGNMENT FAILURE Message 
Type 


Message Type 


11.4 


M 


V 


1 




RR Cause 


RR Cause 


11.5.2.31 


M 


V 


1 



10.1.5 Channel mode modify 

This message is sent on the main S-DCCH by the network to the MES to request the changing of the mode for the 
indicated channel (see table 10.1.5.1). 

Message Type: CHANNEL MODE MODIFY 

Significance: Local 
Direction: Network to MES 
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Table 10.1.5.1 : CHANNEL MODE MODIFY message content 





inTOiiTiaiion ciemeni 


Type 


neierence 


rresence 


rorrnai 


Lengin 




nil ividi ici^d 1 1 CI 11 1 i\JHJLi\Ji 

Discriminator 


Prntnml 

Discriminator 


1 1 .2 


IVI 


v 


1/? 

1 / ^ 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




CHANNEL MODE MODIFY 

IVIessage Type 


Message Type 


11.4 


M 


V 


1 




Cliannel Description 


Channel Description 


11.5.2.5 


M 


V 


4 




Forward Epoch Delay 


Forward Epoch 
Delay 


1 1 .5.2.46 


M 


V 


2 




Channel Mode 


Channel Mode 


11.5.2.6 


M 


V 


1 



10.1.6 Channel mode modify acknowledge 

This message is sent on the main S-DCCH by the MES to the network to indicate the successful or unsuccessful 
execution of a channel mode modify request (see table 10.1.6.1). 

Message Type: CHANNEL MODE MODIFY ACKNOWLEDGE 

Significance: Local 

Direction: MES to network 



Table 10.1.6.1 : CHANNEL MODE MODIFY ACKNOWLEDGE message content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




CHANNEL IVIODE IVIODIFY 


Message Type 


11.4 


M 


V 


1 




Acknowledge IVIessage Type 














Channel Description 


Channel Description 


11.5.2.5 


M 


V 


4 




Channel Mode 


Channel Mode 


11.5.2.6 


M 


V 


1 



10.1.7 Channel release 

This message is sent on the main S-DCCH from the network to the MES to initiate deactivation of the dedicated 
channel used (see table 10.1.7.1). 

Message Type: CHANNEL RELEASE 

Significance: Dual 

Direction: Network to MES 



Table 10.1.7.1: CHANNEL RELEASE message content 



IE! 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




CHANNEL RELEASE Message 
Type 


Message Type 


11.4 


M 


V 


1 




RR Cause 


RR Cause 


11.5.2.31 


M 


V 


1 



10.1.8 Channel request 

This message is sent in random mode on the S-RACH. It does not follow the basic format. The possible formats are 
presented in figure 10.1.8.1, without reference to information fields. 
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This message does not follow the basic format for L3 messages. In addition, the bit ordering may not conform to the 
general field mapping convention in GMR-2 04.006 [15] since the length of the message is not equal to an integer 
number of octets. However the message conforms to the bit transmission convention in GMR-2 04.007 [16] and all bits 
are transmitted according to it. 



8 



1 



Establishment Cause / Random Access (Half Octet A) 


Message (Half Octet B) 


Message (Half Octet C) 


Message (Half Octet D) 


Message (Half Octet E) 


Message (Half Octet F) 




Message (Half Octet G) 



Octet 1 
Octet 2 
Octet 3 
Octet 4 



Figure 10.1.8.1: CHANNEL REQUEST message format 
Table 10.1.8.1: CHANNEL REQUEST message content 



Half Octet 


A 


B, C, D, E, F 


G 


Bits 

Message Type 


8 


7 


6 


5 


see 10.1.8.2, 10.1.8.3 and 10.1.8.4 


4,3 


2,1 


MES Origination 








R 


R 


International Number 


SV 


AN 


Other procedures requiring a S- 
DCCH (see note) 





1 


R 


R 


Subscriber IMSI Number 


11 


AN 


Emergency 





1 


R 


R 


Subscriber IMS Number 


00 


AN 


Emergency (local) 





1 


R 


R 


International Number 


01 


AN 


Location Updating 


1 





R 


R 


Subscriber IMSI Number 


sv 


AN 


Answer to paging 


1 


1 


R 


R 


Paging Reference (22 IMSI bits) 


AN 


R is a bit of the RA defined below. 
Other Parameters defined below 

NOTE: Examples of these procedures are Short Message Service (SMS) and Supplementary Service Management 



10.1.8.1 Random Access (RA) 

The MES shall generate a Random Access Reference number for every Channel Request Message as shown above. The 
RA is a binary number, with a length two as shown in table 10.1.8.1. The most significant bit shall be inserted into bit 6 
of octet 1 (Half-Octet A) as shown in table 10.1.8.1. 

1 0.1 .8.2 Subscriber IMSI number 

The first six digits of the subscriber's IMSI number, containing the MCC and MNC, shall be converted to a 20-bit-long 
binary number and inserted in Half Octets B, C, D, E, F as shown above. The MSB shall be inserted in bit 4, octet 1 
(Half Octet B). The LSB shall be inserted in bit 1, octet 3 (Half Octet F). The most significant digit (MSD) of the 
truncated six-digit IMSI number, prior to binary conversion, shall be the leftmost digit of the MCC when the IMSI is 
ordered from left to right, starting with the MCC digit. 

For definition of "number," see ITU-T Recommendation 1.330 [38] and GMR-2 03.003 [7]. 

These requirements shall apply to the Other Procedures Requiring an S-SDCCH, Emergency, and Location Updating 
message types. 

10.1.8.3 International number 

The first six digits of the International Number shall be converted to a 20-bit-long binary number and inserted in Half 
Octets B, C, D, E, F as shown above. The MSB shall be inserted in bit 4, octet 1 (Half Octet B). The LSB shall be 
inserted in bit 1, octet 3 (Half Octet F). The number shall correspond to the ISDN/telephony numbering plan 
(ITU-T Recommendation E. 163 [34]/E. 164 [35]). The Most Significant Digit (MSD) of the truncated six-digit number, 
prior to binary conversion, shall be the first digit of an international country code when the International Number is 
ordered from left to right, starting with the International Country Code digits. 

For definition of "number", see ITU-T Recommendation 1.330 [38] and GMR-2 03.003 [7]. Prefix or escape digits shall 
not be used. 

If the dialled number is an international type of number, the dialed number shall be used. 
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For other types of numbers (unknown, national, network specific, or a dedicated access (short code)), the MES is 
required to supply the first six digits representing the Country Code and National Destination code through its user 
interface prior to call initiation. Otherwise, the Other Procedures Requiring an S-SDCCH shall be used for originations. 

These requirements shall apply to the MES Origination and Emergency (local) message types. 

10.1.8.4 Paging references 

For the Answer to Paging message type, the MES shall supply the least significant 22 bits of the IMSI from the page 
message. These 22 bits shall occupy Half Octets B, C, D, E, F and bits 4-3 in Half Octet G. The MES shall insert the 
MSB of the 22 bit number in bit 4, octet 1. The LSB +1 and LSB shall be inserted in bit 4 and 3, octet 4. 

10.1.8.5 Satellite Visibility (SV) 

The Satellite Visibility field indicates which satellites are visible to the MES in a multi-spacecraft constellation. The 
MES shall report on the two satellites other than the one to which it is sending a charmel request. The bl values upon 
which the reporting is based are defined by the System Information Type 7 message lEI (clause 11.5.2.22). Each value, 
"1" or "2", is uniquely associated with a Satellite System Code, lEI 11.5.2.44, which specifies a satellite. The MES shall 
report the SV parameter as defined in table 10.1.8.2. 

Table 10.1.8.2: Satellite visibility parameter definition 



Satellite Visibility 
(based on bi value) 


SV 


No other Satellite visible 

"1" visible 

"2" visible 
Both "1" and "2" visible 




SV= 1 
SV = 2 
SV = 3 



The MSB shall be inserted into bit 4, octet 4 (Half Octet G) of the MES Origination and Location Updating message 
types. 

This requirement shall be mandatory for the MES and optional for the NCC. 

10.1 .8.6 Attempt Number (AN) 

The MES shall number each channel request for an access session sequentially using the parameter AN. This parameter 
shall be a binary number from 1 to 4 with most significant bit in bit 2, octet 4 (Half Octet G), using the following 
encoding scheme: 



MSB 


LSB 


Attempt Number 


0, 





= 1 


0, 


1 


= 2 


1, 





= 3 


1, 


1 


= 4 or greater 



If an access session includes more than 4 charmel requests, the MES shall number the fourth and the rest of the charmel 
requests within the session wdth the same binary '11' as above. 

1 0.1 .8.7 Location updating with follow-on 

The MES is allowed to use a CHANNEL REQUEST message of type MES Origination or Other Procedures Requiring 
a S-SDCCH when establishing a RR connection for a LOCATION UPDATING procedure with a "follow-on" CM 
service request (see clause 5.5.1.1). 

1 0.1 .9 Ciphering mode command 

This message is sent on the main S-DCCH from the Network to the MES to indicate that the network has started 
deciphering and that enciphering and deciphering shall be started in the MES, or to indicate that ciphering will not be 
performed (see table 10.1.9.1). 
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Message Type: CIPHERING MODE COMMAND 
Significance: Dual 
Direction: Network to MES 



Table 10.1.9.1: CIPHERING MODE COMMAND Message Content 



IE! 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




CIPHER MODE COMMAND 
Message Type 


Message Type 


11.4 


M 


V 


1 




Ciphering Mode Setting 


Cipher Mode Setting 


11.5.2.9 


M 


V 


1/2 




Cipher Response 


Cipher Response 


11.5.2.10 


M 


V 


1/2 



10.1.10 Ciphering mode complete 

This message is sent on the main S-DCCH from the MES to the Network to indicate that enciphering and deciphering 
has been started in the MES (see table 10.1.10). 

Message Type: CIPHERING MODE COMPLETE 

Significance: Dual 

Direction: MES to Network 



Table 10.1.10.1: CIPHERING MODE COMMAND Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




CIPHER MODE COMPLETE 

message type 


Message Type 


11.4 


M 


V 


1 


17 


Mobile Equipment Identity 


Mobile Identity 


11.5.1.4 





TLV 


10 -11 



1 0.1 .1 0.1 Mobile Equipment Identity 

This information element is included if and only if the MES shall include its IMEISV (see clause 4.4.7). This 
information element shall only refer to IMEISV. 

10.1.11 Classmark change 

This message is sent on the main S-DCCH by the MES to the Network to indicate a classmark change or as a response 
to a classmark enquiry (see table 10.1.11). 

Message Type: CLASSMARK CHANGE 

Significance: Dual 

Direction: MES to Network 
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Table 10.1.11.1 : CLASSMARK CHANGE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Classmark Change Message Type 


Message Type 


11.4 


M 


V 


1 




MES Classmark 


MES Classmark 2 


11.5.1.6 


M 


LV 


4 


20 


Additional MES Classmark 
Information 


MES Classmark 3 


11.5.1.7 





TLV 


14 



10.1.11.1 Additional MES classmark information 

This IE shall be included if and only if the CM3 bit in the MES Classmark IE is set to "additional MES capabilities are 
described in the Classmark 2 information element." This information element is not supported in the network. 

10.1.12 Classmark enquiry 

This message is sent on the main S-DCCH by the network to the MES to request classmark information (see table 
10.1.12.1). 

Message Type: CLASSMARK ENQUIRY 
Significance: Dual 
Direction: Network to MES 



Table 10.1.12.1: CLASS ENQUIRY Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Classmark Enquiry Message Type 


Message Type 


11.4 


M 


V 


1 



10.1.13 Frequency redefinition 

This clause does not apply to the GMR-2 system. 

10.1.14 Handover access 

This clause does not apply to the GMR-2 system. 

10.1.15 Handover command 

This clause does not apply to the GMR-2 system. 

10.1.16 Handover complete 

This clause does not apply to the GMR-2 system. 

10.1.17 Handover failure 

This clause does not apply to the GMR-2 system. 
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10.1.18 Immediate assignment 

This message is sent on the S-AGCH by the Network to the MES in idle mode to change the channel configuration to a 
dedicated configuration while staying in the same spotbeam (see table 10.1.18.1). 

The L2 pseudo length of this message is 17 octets. 

Message Type: IMMEDIATE ASSIGNMENT 

Significance: Dual 

Direction: Network to MES 



Table 10.1.18.1: IMMEDIATE ASSIGNMENT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




L2 Pseudo Length 


L2 Pseudo Length 


11.5.2.19 


M 


V 


1 




RR Management Protocol 
Discriminator 


ProtQCo! 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Immediate Assignment Message 
Type 


Message Type 


11.4 


M 


V 


1 




Page IVIode 


Page Mode 


11.5.2.26 


M 


V 


1/2 




Spare Half Octet 


Spare Half Octet 


11.5.1.8 


M 


V 


1/2 




Channel Description 


Channel Description 


11.5.2.5 


M 


V 


4 




Forward Epoch Delay 


Forward Epoch 
Delay 


1 1 .5.2.46 


M 


V 


2 




Request Reference 


Request Reference 


11.5.2.30 


M 


V 


6 




Timing Advance 


Fine Timing 
Advance 


11.5.2.40 


M 


V 


2 



10.1.19 Immediate assignment extended 

This clause does not apply to the GMR-2 system. 

10.1.20 Immediate assignment reject 

This message is sent on the S-AGCH by the Network to indicate that no channel is available for assigrmient (see table 
10.1.20.1). This message has L2 pseudo length 10. 

Message Type: IMMEDIATE ASSIGNMENT REJECT 

Significance: Dual 

Direction: Network To MES 



Table 10.1.20.1: IMMEDIATE ASSIGNMENT REJECT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




L2 Pseudo Length 


L2 Pseudo Length 


11.5.2.19 


M 


V 


1 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Immediate Assignment Reject 
Message Type 


Message Type 


11.4 


M 


V 


1 




Page Mode 


Page Mode 


11.5.2.26 


M 


V 


1/2 




Spare Half Octet 


Spare Half Octet 


11.5.1.8 


M 


V 


1/2 




Request Reference 


Request Reference 


11.5.2.30 


M 


V 


6 




Wait Indication 


Wait Indication 


11.5.2.43 


M 


V 


1 
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10.1.20.1 Use of the indexes 

This clause does not apply to the GMR-2 system. 

1 0.1 .20.2 Filling of the Message 

Octets 12-18 shall be filled with all I's. The rest of the message shall be fill to 23 octets as specified in 
GMR-2 04.006 [15]. 

10.1.21 Measurement report 

This message is sent on the S-SACCH by the MES to the Network to report measurement results about the dedicated 
channel (see table 10.1.21.1). 

Message Type: MEASUREMENT REPORT 

Significance: Dual 

Direction: MES to Network 



Table 10.1.21.1: MEASUREMENT REPORT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Measurement Report Message 
Type 


Message Type 


11.4 


M 


V 


1 




Measurement Results 


Measurement 
Results 


11.5.2.20 


M 


V 


3 



10.1.22 Paging Request Type 1 

This message is sent on the S-PCH by the Network to a single MES as defined in clause 4.3.2.1. This message is used to 
trigger channel access. The MES is identified by its IMSI (see table 10.1.22.1). 

The L2 pseudo length of this message is the sum of lengths of all information elements present in the message except 
the PI Rest Octets and L2 Pseudo Length information elements. 

Message Type: PAGING REQUEST TYPE 1 

Significance: Dual 

Direction: Network to MES 



Table 10.1.22.1: PAGING REQUEST TYPE 1 Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




L2 Pseudo Length 


L2 Pseudo Length 


11.5.2.19 


M 


V 


1 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Paging Request Type 1 Message 
Type 


Message Type 


11.4 


M 


V 


1 




Page Mode 


Page Mode 


1 1 .5.2.26 


M 


V 


1/2 




Channel Needed 


Channel Needed 


11.5.2.8 


M 


V 


1/2 




Mobile Identity 


Mobile Identity 


11.5.1.4 


M 


LV 


9 




Paging Reference Request 


Paging Reference 
Request 


1 1 .5.2.50 


M 


V 


2 




PI Rest Octets 


PI Rest Octets 


1 1 .5.2.23 


M 


V 


5-8 
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10.1.22.1 Unnecessary IE 

A MES in idle mode shall consider all information elements as unnecessary lEs except for the Page Mode IE. 

1 0.1 .22.2 Channel needed for mobile identity 

The CHANNEL field of the Channel Needed IE is associated with the Mobile Identity. 

10.1.22.3 Mobile Identity 

The Mobile Identity IE shall use IMSI. 

10.1.22.4 PI rest octets 

The sum of the length of this IE and the L2 Pseudo Length of the message equals 22. 

10.1.23 Paging request type 2 

This clause does not apply to the GMR-2 system. 

1 0. 1 .24 Paging request type 3 

This clause does not apply to the GMR-2 system. 

10.1.25 Paging response 

This message is sent on the main S-DCCH by the MES to the Network in connection with establishment of the main 
signalling link as a response to the paging request message (see table 10.1.25.1). 

Message Type: PAGING RESPONSE 

Significance: Dual 

Direction: MES to Network 



Table 10.1.25.1: PAGING RESPONSE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Paging Response IVlessage Type 


Message Type 


11.4 


M 


V 


1 




Ciphering Key Sequence Number 


Ciphering Key 
Sequence Number 


11.5.1.2 


M 


V 


1/2 




Spare Half Octet 


Spare Half Octet 


11.5.1.8 


M 


V 


1/2 




MES Classmark 


MES Classmark 2 


11.5.1.6 


M 


LV 


4 




Mobile Identity 


Mobile Identity 


11.5.1.4 


M 


LV 


9 




Location Area Code 


LAC 


1 1 .2.5.48 


M 


V 


2 



1 0.1 .25.1 Location Area Code 

The Location Area Code consists of the LAC portion on the LAI. 

10.1.25.2 Mobile Identity 

The MES shall use the IMSI. 
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10.1.26 Partial release 

This clause does not apply to the GMR-2 system. 

1 0. 1 .27 Partial release complete 

This clause does not apply to the GMR-2 system. 

10.1.28 Physical information 

This clause does not apply to the GMR-2 system. 

10.1.29 RR status 

This message is sent by the MES or the Network at any time to report certain error conditions as described in clause 9 
(see table 10.1.29.1). 

Message Type: RR STATUS 

Significance: Local 

Direction: Both 



Table 10.1.29.1 : RR STATUS Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 


Protocol 


11.2 


M 


V 


1/2 




Discriminator 


Discriminator 












Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




RR Status Message Type 


Message Type 


11.4 


M 


V 


1 




RR Cause 


RR Cause 


11.5.2.31 


M 


V 


1 



1 0. 1 .30 Synchronization channel information 

This message is sent on the S-SCH, which is one of the broadcast channels (see GMR-2 05.002 [23]). Its purpose is to 
support the synchronization of a MES to the Network. It does not follow the basic format. Its length is 25 bits. See 
figure 10.1.30.1 and table 10.1.30.1. 

This message does not follow the basic format for L3 messages. In addition, the bit ordering may not conform to the 
general field mapping convention in GMR-2 04.006 [15] since the length of the message is not equal to an integer 
number of octets. However, the message conforms to the bit transmission convention in GMR-2 04.004 [13] and all bits 
are transmitted according to it. 

Message Type: SYNCHRONISATION CHANNEL INFORMATION 

Significance: Dual 



Direction: 



Network To MES 



8 7 6 5 4 3 2 1 


Spotbeam Identification Code (SBIG) 
NCC BCCC 


T1 (high) 


T1 (middle) 


T1 

(low) 


T2 


T3' (high) 




T3' 
(low) 



octet 1 

octet 2 
octet 3 

octet 4 



Figure 10.1.30.1: Frame Synchronization Information Element 
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Table 10.1.30.1: Synchronization Cliannel Information Message Contents 



The Spotbeam Identification Code (SBIC) component NCC occupies bits 8, 7, and 6 of octet 1 
with the MSB in bit 8. 

The Spotbeam Identification Code (SBIC) component BCCC occupies bits 5, 4, and 3 with the 
MSB in bit 5. 

T1 , T2, and T3' are the three parts of the reduced TDMA frame number (RFN) as specified in 
GMR-2 05.002 [23]. 



10.1.31 System information type 1 

This clause does not apply to the GMR-2 system. 

10.1 .32 System information type 2 

This message is sent on the S-BCCH by the Network to all MESs within the spotbeam giving information of control of 
the S-RACH and of the S-BCCH allocation in the neighbor spotbeams (see table 10.1.32.1). Special requirements for 
the transmission of this message apply, see GMR-2 05.002 [23]. This message has a L2 Pseudo Length of 21. 

Message Type: SYSTEM INFORMATION TYPE 2 

Significance: Dual 

Direction: Network to MES 



Table 10.1.32.1 : SYSTEM INFORMATION TYPE 2 Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




L2 Pseudo Length 


L2 Pseudo Length 


11.5.2.19 


M 


V 


1 




RR IVIanagement Protocol 


Protocol 


11.2 


M 


V 


1/2 




Discriminator 


Discriminator 












Sl<ip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




System Information Type 2 
IVIessage Type 


Message Type 


11.4 


M 


V 


1 




S-BCCH Frequency List 


Neighbour 
Spotbeam 

Description 


1 1 .5.2.22 


M 


V 


15 




Network Colour Code Permitted 


Network Colour 
Code Permitted 


11.5.2.27 


M 


V 


1 




S-RACH Control Parameter 


S-RACH Control 
Parameters 


11.5.2.29 


M 


V 


3 



1 0.1 .33 System information type 2bis 

This clause does not apply to the GMR-2 system. 

1 0. 1 .34 System information type 3 

This message is sent on the S-BCCH by the Network giving information of control on the S-RACH, the location area 
identification, the spotbeam identity and various other information about the beam (see table 10.1.34.1). Special 
requirements for the transmission of this message apply, see GMR-2 05.002 [23]. This message has a L2 Pseudo Length 
of 18. 

Message Type: SYSTEM INFORMATION TYPE 3 
Significance: Dual 
Direction: Network to MES 
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Table 10.1.34.1 : SYSTEM INFORMATION TYPE 3 Message Content 



Itl 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




L2 Pseudo Length 


L2 Pseudo Length 


11.5.2.19 


M 


V 


1 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


1 1 .2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




System Information Type 3 
Message Type 


Message Type 


1 1 .4 


Ik A 


V 


1 




Location Area Identification 


Location Area 
Identification 


1 1 .5.1 .3 


M 


V 


5 




Control Channel Description 


Control Channel 
Description 


11.5.2.11 


M 


V 


3 




Spotbeam Options 


Spotbeam Options 


11.5.2.3 


M 


V 


1 




Spotbeam Selection Parameters 


Spotbeam Selection 
Parameters 


11.5.2.4 


M 


V 


2 




S-RACH Control Parameters 


S-RACH Control 

Parameters 


1 1 .5.2.29 


M 


V 


3 




Spotbeam Re-selection Parameters 


Spotbeam Re- 
selection 
Parameters 


11.5.2.34 


M 


V 


2 



1 0. 1 .35 System information type 3 

This clause does not apply to the GMR-2 system. 

1 0. 1 .36 System information type 4 

This clause does not apply to the GMR-2 system. 

1 0. 1 .37 System information type 5 

This clause does not apply to the GMR-2 system. 

1 0.1 .38 System information type 5bis 

This clause does not apply to the GMR-2 system. 

1 0. 1 .39 System information type 5ter 

This clause does not apply to the GMR-2 system. 

1 0. 1 .40 System information type 6 

This message is sent on the S-SACCH by the Network to MESs to determine link Radio-Link Timeout variable and 
DTX setting (see table 10.1.40.1). If received correctly by the MES, this message is treated as in clauses 10.1.40.1 
through 10.1.40.4. 

Message Type: SYSTEM INFORMATION TYPE 6 
Significance: Dual 
Direction: Network to MES 



ETSI 



GMR-2 04.008 1 27 ETSI TS 1 01 377-4-7 V1 .1 .1 (2001 -03) 



Table 10.1.40.1 : SYSTEM INFORMATION TYPE 6 Message Content 



IPI 


iiiTor iTiaiion d6in6ni 


Type 


ri6T6r6nc6 


presence 


ror iTiai 


Lengin 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




System Information Type 6 
Message Type 


Message Type 


11.4 


M 


V 


1 




Spotbeam Options 


Spotbeam 
Options 


11.5.2.3 


M 


V 


1 



10.1.40.1 Cell Identity 

This clause does not apply to the GMR-2 system. 

1 0.1 .40.2 Location Area Identification 

This clause does not apply to the GMR-2 system. 

1 0. 1 .40.3 Spotbeam options 

After assignment it is used for the duration of the connection after which the S-BCCH value is used. 

10.1 .41 System Information Type 7 (GMR-2 option) 

This message is sent on the S-BCCH and S-HBCCH by the Network giving information about other satellite systems 
that are geographically near the spotbeam in which the message is broadcast (see table 10.1.41.1). Special requirements 
for the transmission of this message apply, see GMR-2 05.002 [23]. 

Message Type: SYSTEM INFORMATION TYPE 7 

Significance: Dual 

Direction: Network to MES 



Table 10.1.41.1 : SYSTEM INFORMATION TYPE 7 Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR IVIanagement Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




System Information Type 7 
Message Type 


Message Type 


11.4 


M 


V 


1 




CCS Frequency List 


Neighbour 
Spotbeam 
Description 


1 1 .5.2.22 


M 


V 


18 




Satellite System Description 


Satellite System 
Code 


1 1 .5.2.44 


M 


V 


3 
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10.1 .42 System Information Type 8 

This message is sent on the S-BCCH and the S-HBCCH by the Network giving information about spotbeam frequencies 
in use on the satellite (see table 10.1.42.1). Special requirements for the transmission of this message apply, see 
GMR-2 05.002 [23]. 

Message Type: SYSTEM INFORMATION TYPE 8 
Significance: Dual 
Direction: Network to MES 



Table 10.1.42.1 : SYSTEM INFORMATION TYPE 8 Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Sl<ip Indicator 


11.3.1 


M 


V 


1/2 




System Information Type 8 
Message Type 


Message Type 


11.4 


M 


V 


1 




Satellite Frequency List 


Satellite Frequency 
Description 


11.5.2.51 


M 


V 


21 



10.1 .43 System Information Type 9 

This message is sent on the S-BCCH by the Network to all MESs within the spotbeam giving information about the 
Common Channel Signal Configuration, the Forward Epoch Delay, and the HPA configuration that is used on the 
Common Channel Signal transmission (see table 10.1.43.1). 

Special requirements for the transmission of this message apply, see GMR-2 05.002 [23]. 

The L2 pseudo Length of this message is the sum of all information elements present in the message except the L2 
Pseudo Length information element. 

Message Type: SYSTEM INFORMATION TYPE 9 

Significance: Dual 

Direction: Network to MES 



Table 10.1.43.1 : SYSTEM INFORMATION TYPE 9 Message Content 



IE! 


Information Element 


Type 


Reference 


Presence 


Format 


Lengthi 




L2 Pseudo Length 


L2 Pseudo Length 


11.5.2.19 


M 


V 


1 




RR Management Protocol 

Discriminator 


Protocol 

Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




System Information Type 9 
Message Type 


Message Type 


11.4 


M 


V 


1 




Common Channel Configuration 


CCS Configuration 
Parameters 


1 1 .5.2.45 


M 


V 


4 




Forward Epoch Delay 


Forward Epoch 

Delay 


11.5.2.46 


M 


V 


2 




HPA Configuration 


HPA Configuration 


11.5.2.47 


M 


V 


5 




S-RACH Control Parameters 


S-RACH Control 
Parameters 


1 1 .5.2.29 


M 


V 


3 



10.1.44 System Information Type 10 

This message is sent on the S-BCCH by the Network to all MESs within the spotbeam giving information about the 
valid beam pairs for inclined orbit operations (see table 10.1.44.1). 
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Special requirements for the transmission of this message apply, see GMR-2 05.002 [23]. 

The L2 pseudo Length of this message is the sum of all information elements present in the message except the L2 
Pseudo Length information element. 

Message Type: SYSTEM INFORMATION TYPE 10 

Significance: Dual 

Direction: Network to MES 



Table 10.1.44.1 : SYSTEM INFORMATION TYPE 10 Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




L2 Pseudo Length 


L2 Pseudo Length 


11.5.2.19 


M 


V 


1 




RR management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Sl<ip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




System Information Type 10 
Message Type 


Message Type 


11.4 


M 


V 


1 




Single Spotbeam LAC 


Location Area Code 


1 1 .5.2.48 


M 


V 


2 




Inclined Orbit Beam Pairs 1 


Location Area Code 


1 1 .5.2.48 


M 


V 


2 




Inclined Orbit Beam Pairs 2 


Location Area Code 


11.5.2.48 


M 


V 


2 




Inclined Orbit Beam Pairs 3 


Location Area Code 


11.5.2.48 


M 


V 


2 




Inclined Orbit Beam Pairs 4 


Location Area Code 


11.5.2.48 


M 


V 


2 




Inclined Orbit Beam Pairs 5 


Location Area Code 


1 1 .5.2.48 


M 


V 


2 




Inclined Orbit Beam Pairs 6 


Location Area Code 


1 1 .5.2.48 


M 


V 


2 




Beam-Pair LU Timer 


BP LU Timer 


11.5.2.49 


M 


V 


1 




S-RACH Control Parameters 


S-RACH Control 
Parameters 


11.5.2.49 


M 


V 


3 



10.1.45 Paging Request-HPACH IMSI 



This message is sent on the S-HPACH by the Network to a single MES to trigger channel access or MES disable/enable 
notification. The MES is identified by its IMSI (see figure 10.1.45.1). 

This message does not follow the basic format for L3 messages. In addition, the bit ordering may not conform to the 
general field mapping convention in GMR-2 04.006 [15] clause since the length of the message is not equal to an 
integer number of octets. However, the message conforms to the bit transmission convention in GMR-2 04.004 [13] and 
all bits are transmitted according to it. 

Message Type: Paging Request-HPACH IMSI 

Significance: Dual 

Direction: Network to MES 

8 7 6 5 4 3 2 1 



Mobile Paging Identity, (LS), 10.1.45.1 



Mobile Paging Identity, 10.1.45.1 



Mobile Paging Identity, 10.1.45.1 



Mobile Paging Identity, 10.1.45.1 



Mobile Paging Identity, 10.1.45.1 



Mobile Paging Identity, 10.1.45.1 



MES TX Disable/Enable | MPI 10.1.45.2 (MS) 



octet 1 
octet 2 
octet 3 
octet 4 
octet 5 
octet 6 
octet 7 



Figure 10.1.45.1: PAGING REQUEST-HPACH IMSI Message 



1 0.1 .45.1 Mobile paging identity 

This IE occupies octets 1-6 and bits 1-2 in octet 7. It has the following contents. 
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The paged IMSI is converted to a 50-bit-long binary number. The least significant bit of this IMSI presentation is 
inserted in bit 1, octet 1. The Most Significant bit is inserted in bit 2, octet 7. The rest of the bits are inserted according 
to figure 10.1.45.2 (index 1 denotes the LS bit, index 50 denotes the MS bit). 



8 


7 


6 


5 


4 


3 


2 


1 


8 


7 


6 


5 


4 


3 


2 


1 


16 


15 


14 


13 


12 


11 


10 


9 



octet 1 
octet 2 



48 


47 


46 


45 


44 


43 


42 


41 




MES TX Disable/Enable 


50 


49 



octet 6 
octet 7 



Figure 10.1.45.2: Mapping of IIUISI bits into PAGING REQUEST H-PACH liUlSI iUlessage 



10.1.45.2 MES TX Disable/Enable 

This IE occupies bits 3-5 in octet 7. The MES TX Disable/Enable message type is a binary value used to specify the 
transmit status of a specific MES. 

Bit 5 Bit 4 Bit 3 

Normal Paging 

1 1 Transmit Disable 
1 1 Transmit Enable 



10.1.46 Transmit Disable 

This message is sent by the Network to the User Terminal to notify that transmission from the terminal has to be 
disabled. 

Message Type: TRANSMIT DISABLE 

Significance: Dual 

Direction: Network To User Terminal 



Table 10.1.46.1 : TRANSMIT DISABLE Message Content 



lEI 


information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Transmit Disable Message Type 


Message Type 


11.4 


M 


V 


1 



1 0. 1 .47 Transmit Disable Acknowledgement 

This message is sent by the User Terminal to the Network to acknowledge the receipt of transmit disable message. 

Message Type: TRANSMIT DISABLE ACK 

Significance: Dual 

Direction: User Terminal To Network 
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Table 10.1.47.1 : TRANSMIT DISABLE ACK Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




RR Management Protocol Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Transmit Disable Message Type 


Message Type 


11.4 


M 


V 


1 



1 0. 1 .48 H-BCCH version number 

This message is sent on the S-HBCCH by the Network giving information on version number of the System 
Information messages that follow it on the H-BCCH broadcast. 

This message does not follow the basic format for L3 messages. In addition, the bit ordering may not conform to the 
general tield mapping convention in GMR-2 04.006 [15] since the length of the message is not equal to an integer 
number of octets. However, the message conforms to the bit transmission convention in GMR-2 04.004 [13] and all bits 
are transmitted according to it. 



8 


7 


6 


5 


4 3 


2 1 






SIM Type 






Sequence Number 


octet 1 




Spare 


octet 2 



Figure 10.1.48.1: H-BCCH VERSION NUMBER Message Format 
Table 10.1.48.1: H-BCCH VERSION NUMBER Message Content 



SIM Type (octet 1, bits 8 to 6) 

Tlie System Information Message (SIM) Type is a binary value used to identify the contents of 
the following System Information message. The MSB is in bit 8. The parameter is encoded with 
the MSB being the left most bit as shown below: 

Type 2 

1 Type 3 

1 Type 9 
Oil Type 10 

1 Type 8 current satellite frequency list 

1 1 Type 8 pending satellite frequency list 

1 1 Type 7 multisat frequency list 

1 1 1 Spare 

Sequence Number (Octet 1 , bits 5 to 1) 

A binary number used to indicate the version of tine following message. Tlie MSB is in bit 5. 



1 0.2 Messages for mobility management 

Table 10.2.1 summarizes the messages for Mobility Management. 
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Table 10.2.1 : Messages for Mobility Management 



Registration messages: 


Reference 


LOCATION UPDATING ACCEPT 


10.2.13 


LOCATION UPDATING REJECT 


10.2.14 


LOCATION UPDATING REQUEST 


10.2.15 


Security messages: 


Reference 


AUTHENTICATION REJECT 


10.2.1 


AUTHENTICATION REQUEST 


10.2.2 


AUTHENTICATION RESPONSE 


10.2.3 


IDENTITY REQUEST 


10.2.10 


IDENTITY RESPONSE 


10.2.11 


Connection management messages: 


Reference 


CM SERVICE ACCEPT 


10.2.5 


CM SERVICE REJECT 


10.2.6 


CM SERVICE ABORT 


10.2.7 


CM SERVICE REQUEST 


10.2.9 


Miscellaneous message 


Reference 


MM Status 


10.2.16 



10.2.1 Authentication reject 

This message is sent by the Network to the MES to indicate that authentication has failed (and that the receiving MES 
shall abort all activities). See table 10.2.1.1. 

Message Type: AUTHENTICATION REJECT 

Significance: Dual 

Direction: Network to MES 



Table 10.2.1.1 : AUTHENICATION REJECT Message Content 



lEI 


information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Authentication Reject Message 
Type 


Message Type 


11.4 


M 


V 


1 



10.2.2 Autlientication request 

This message is sent by the Network to the MES to initiate authentication of the MES identity. See table 10.2.2.1. 
Message Type: AUTHENTICATION REQUEST 
Significance: Dual 
Direction: Network to MES 
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Table 10.2.2.1 : AUTHENICATION REQUEST Message Content 





inTOiiTiaiion ciemeni 


Type 


neTerencs 


rresence 


rormai 


Lengin 




Mobility Management Protocol 

1 OLfl MINI IdlUl 


Protocol 

r^iQpriminatnr 

1 OOI MINI IdlL/l 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Authentication Request IVIessage 
Type 


Message Type 


11.4 


M 


V 


1 




Ciphering Key Sequence Number 


Ciphering Key 
Sequence Number 


11.5.1.2 


M 


V 


1/2 




Spare Half Octet 


Spare Half Octet 


11.5.1.8 


M 


V 


1/2 




Authentication Parameter RAND 


Auth. Parameter 
RAND 


11.5.3.1 


M 


V 


16 



10.2.3 Authentication response 

This message is sent by the MES to the Network to deliver a calculated response to the Network. See table 10.2.3.1. 
Message Type: AUTHENTICATION RESPONSE 
Significance: Dual 
Direction: MES to Network 



Table 10.2.3.1: AUTHENTICATION RESPONSE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Authentication Response Message 
Type 


Message Type 


11.4 


M 


V 


1 




Authentication Parameter SRES 


Auth. Parameter 
SRES 


11.5.3.2 


M 


V 


4 



10.2.4 CIVl Re-establishment request 

This clause does not apply to the GMR-2 system. 

1 0.2.5 CiVI service accept 

This message is sent by the Network to the MES to indicate that the requested service has been accepted. See table 
10.2.5.1. 

Message Type: CM SERVICE ACCEPT 
Significance: Dual 
Direction: Network to MES 



Table 10.2.5.1 : CM SERVICE ACCEPT Message Content 



IE! 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




CM Service Accept Message Type 


Message Type 


11.4 


M 


V 


1 
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10.2.6 CM service reject 

This message is sent by the Network to the MES to indicate that the requested service cannot be provided. See table 
10.2.6.1. 

Message Type: CM SERVICE REJECT 
Significance: Dual 
Direction: Network to MES 



Table 10.2.6.1 : CM SERVICE REJECT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility l\/lanagement Protocol 
Discriminator 


Protocol 

Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




CM Service Reject Message Type 


Message Type 


11.4 


M 


V 


1 




Reject Cause 


Reject Cause 


11.5.3.6 


M 


V 


1 



10.2.7 CM service abort 

This message is sent by the MES to the Network to request the abort of the first MM connection establishment in 
progress and the release of the RR connection. See table 10.2.7.1. 

Message Type: CM SERVICE ABORT 

Significance: Dual 

Direction: MES to Network 



Table 10.2.7.1 : CM SERVICE ABORT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility Management Protocol 

Discriminator 


Protocol 

Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




CM Service Abort Message Type 


Message Type 


11.4 


M 


V 


1 



10.2.8 Abort 

This clause does not apply to the GMR-2 system. 

10.2.9 CM service request 

This message is sent by the MES to the Network to request a service for the connection management sublayer entities, 
e.g., circuit switched coimection establishment, supplementary services activation, etc. See table 10.2.9.1. 

Message Type: CM SERVICE REQUEST 

Significance: Dual 

Direction: MES to Network 
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Table 10.2.9.1 : CM SERVICE REQUEST Message Content 



IPI 

Id 


1 nf /^fm of i/\n Clamant 


Type 


rfcicicncc 




roriTiai 






IvIUUIIIiy IvIdllctLJCIIlclll r lUlULrUI 

Discriminator 


r 1 UlUOUl 

Discriminator 


1 1 .c. 


Ivl 


\/ 

V 






Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




CM Service Request IVIessage Type 


Message Type 


11.4 


M 


V 


1 




CM Service Type 


CM Service Type 


11.5.3.3 


M 


V 


1/2 




Cipliering Key Sequence Number 


Ciphering Key 
Sequence Number 


11.5.1.2 


M 


V 


1/2 




MES Classmark 


MES Classmark 2 


11.5.1.6 


M 


LV 


4 




Mobile Identity 


Mobile Identity 


11.5.1.4 


M 


LV 


9 




Location Area Code 


LAC 


1 1 .5.2.48 


M 


V 


2 



10.2.9.1 Location area code 

The LAC used in this message shall be the LAC portion of the LAI. 

10.2.9.2 Mobile identity 

The MES shall use the IMSI. 



10.2.10 Identity request 

This message is sent by the Network to the MES to request a MES to submit the specified identity to the network. See 
table 10.2.10.1. 

Message Type: IDENTITY REQUEST 
Significance: Dual 
Direction: Network to MES 



Table 10.2.10.1 : IDENTITY REQUEST Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Identity Request Message Type 


Message Type 


11.4 


M 


V 


1 




Identity Type 


Identity Type 


11.5.3.4 


M 


V 


1/2 




Spare Half Octet 


Spare Half Octet 


11.5.1.8 


M 


V 


1/2 



1 0.2.1 1 Identity response 

This message is sent by the MES to the Network in response to an IDENTITY REQUEST message providing the 
requested identity. See table 10.2.11.1. 

Message Type: IDENTITY RESPONSE 

Significance: Dual 

Direction: MES to Network 
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Table 10.2.11.1: IDENTITY RESPONSE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Identity Response Message Type 


Message Type 


11.4 


M 


V 


1 




Mobile Identity 


Mobile Identity 


11.5.1.4 


M 


LV 


9-10 



10.2.12 IMSI detach indication 

This clause does not apply to the GMR-2 system. 

10.2.13 Location updating accept 

This message is sent by the Network to the MES to indicate that updating in the network has been completed. See table 
10.2.13.1 

Message Type: LOCATION UPDATING ACCEPT 
Significance: Dual 
Direction: Network to MES 



Table 10.2.13.1: LOCATION UPDATING ACCEPT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Location Updating Accept Message 
Type 


Message Type 


11.4 


M 


V 


1 




Location Area Identification 


Location Area 

Identification 


11.5.1.3 


M 


V 


5 


17 


Mobile Identity 


Mobile Identity 


11.5.1.4 





TLV 


10 


A1 


Follow On Proceed 


Follow On Proceed 


11.5.3.7 





T 


1 



10.2.13.1 Follow on proceed 

The follow on proceed information element appears if the Network wishes to indicate that the MES may attempt an 
MM connection establishment using the same RR cormection. 

10.2.13.2 Mobile identity 

The Mobile Identity is not sent by the MSC. 

10.2.14 Location updating reject 

This message is sent by the Network to the MES to indicate that updating has failed. See table 10.2.14.1. 
Message Type: LOCATION UPDATING REJECT 
Significance: Dual 
Direction: Network to MES 
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Table 10.2.14.1: LOCATION UPDATING REJECT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility Management Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Location Updating Reject Message 
Type 


Message Type 


11.4 


M 


V 


1 




Reject Cause 


Reject Cause 


11.5.3.6 


M 


V 


1 



10.2.15 Location updating request 

This message is sent by the MES to the Network either to request update of its location tile (normal updating or periodic 
updating). See table 10.2.15.1. 

Message Type: LOCATION UPDATING REQUEST 
Significance: Dual 
Direction: MES to Network 



Table 10.2.15.1: LOCATION UPDATING REQUEST Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Mobility Management Protocol 
Discriminator 


Protocol 

Discriminator 


11.2 


M 


V 


1/2 




Skip Indicator 


Skip Indicator 


11.3.1 


M 


V 


1/2 




Location Updating Request 
Message Type 


Message Type 


11.4 


M 


V 


1 




Location Updating Type 


Location Updating 
Type 


11.5.3.5 


M 


V 


1/2 




Ciphering Key Sequence Number 


Ciphering Key 
Sequence Number 


11.5.1.2 


M 


V 


1/2 




Location Area Identification 


Location Area 
Identification 


11.5.1.3 


M 


V 


5 




MES Classmark 


MES Classmark 1 


11.5.1.5 


M 


V 


1 




Mobile Identity 


Mobile Identity 


11.5.1.4 


M 


LV 


9 




Location Area Code 


LAC 


1 1 .5.2.48 


M 


V 


2 



NOTE: If the IMEI is received as a Mobile Identity, then the received location updating request shall be rejected 
with the cause "IMEI not accepted". 

10.2.15.1 Location Area Identification 

The location area identification stored in the SIM is used. 

1 0.2.1 5.2 Location Area Code 

This is the serving LAC for user registration. It is derived from the System Information message ID and subsequent user 
terminal actions with respect to inclined orbit operations (i.e., single spotbeam or beam pair LAC). 

10.2.15.3 Mobile Identity 

The user terminal shall use the IMSI. 

10.2.16 IVIIVI Status 

The network shall ignore this message if it is sent by the mobile. 
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10.2.17 TMSI reallocation command 

This clause does not apply to the GMR-2 system. 

10.2.18 TMSI reallocation complete 

This clause does not apply to the GMR-2 system. 

1 0.3 IVIessages for circuit-switched call control 

Table 10.3.1 summarizes the messages for circuit-switched call control. 



Table 10.3.1 : Messages for Circuit-Mode Connections Call Control 



Call Establishment Messages: 


Reference 


ALERTING 


10.3.1 


CALL CONFIRMED (see note) 


10.3.2 


CALL PROCEEDING 


10.3.3 


CONNECT 


10.3.5 


CONNECT ACKNOWLEDGE 


10.3.6 


EMERGENCY SETUP (see note) 


10.3.8 


PROGRESS 


10.3.17 


CCTI ID 
ot 1 Ur 




oaii inToriTiaiiun rnasc Mcssaycs. 


rieTcrencc 


MODIFY (see note) 


10.3.13 


MODIFY COMPLETE (see note) 


10.3.14 


MODIFY REJECT (see note) 


10.3.15 


USER INFORMATION 


10.3.31 


Call Clearing Messages: 


Reference 


DISCONNECT 


10.3.7 


RELEASE 


10.3.18 


RELEASE COMPLETE 


10.3.19 


Messages For Supplementary Service Control 


Reference 


FACILITY 


10.3.9 


HOLD (see note) 


10.3.10 


HOLD ACKNOWLEDGE (see note) 


10.3.11 


HOLD REJECT (see note) 


10.3.12 


RETRIEVE (see note) 


10.3.20 


RETRIEVE ACKNOWLEDGE (see note) 


10.3.21 


RETRIEVE REJECT (see note) 


10.3.22 


Miscellaneous Messages: 


Reference 


CONGESTION CONTROL 


10.3.4 


NOTIFY 


10.3.16 


START DTMF (see note) 


10.3.24 


START DTMF ACKNOWLEDGE (see note) 


10.3.25 


START DTMF REJECT (see note) 


10.3.26 


STATUS 


10.3.27 


STATUS ENQUIRY 


10.3.28 


STOP DTMF(see note) 


10.3.29 


STOP DTMF ACKNOWLEDGE (see note) 


10.3.30 


NOTE: Not supported by ITU-T Recommendation 0.931 [43] 
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10.3.1 Alerting 

1 0.3.1 .1 Alerting (Network to MES Direction) 

This message is sent by the Network to the calhng MES to indicate that the called user alerting has been initiated. See 
table 10.3.1.1. 

Message Type: ALERTING 
Significance: Global 
Direction: Network to MES 



Table 10.3.1.1 : ALERTING Message Content (Network to MES direction) 



lEI 


information Element 


Type 


Reference 


Presence 


Format 


Length 




Call Control Protocol Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Transaction Identifier 


Transaction 

Identifier 


11.3.2 


M 


V 


1/2 




Alerting Message Type 


Message Type 


11.4 


M 


V 


1 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


1E 


Progress Indicator 


Progress Indicator 


11.5.4.21 





TLV 


4 


7E 


User-User 


User- User 


1 1 .5.4.25 


o 


TLV 


3-35 



10.3.1.1.1 Facility 

This information element may be used for functional operation of supplementary services. It will not be sent by the 
network (no supplementary services supported in the Network require this). 

1 0.3.1 .1 .2 Progress indicator 

This information element may be included by the Network: 

In order to pass information about the call in progress, e.g., in the event of interworking; and/or 

To make the MES attach the user connection for speech, interworking. 
Refer to clause 6.2.1.4 for the possible values sent by the network (MSG). 

10.3.1.1.3 User -User 

This information element will not be sent (user-to-user service not supported in the network). 

10.3.1 .2 Alerting (MES to Network direction) 

This message is sent by the called MES to the Network, to indicate that the called user alerting has been initiated. See 
table 10.3.1.2. 

Message Type: ALERTING 
Significance: Global 
Direction: MES to Network 
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Table 10.3.1.2: ALERTING Message Content (MES to Network direction) 



IPI 
Id 


1 nf m'n^ f\n CI Ann Ant 

inTormaiiun dcineni 


Type 


D Af APAnAA 


Dpao An AA 

pTesence 


roriTiai 


1 Annth 

Lengin 




Call Control Protocol 
Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Transaction Identifier 


Transaction 
Identifier 


11.3.2 


M 


V 


1/2 




Alerting Message Type 


Message Type 


1 1 .4 


M 


V 


1 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


7E 


User-User 


User-User 


11.5.4.25 





TLV 


3-35 


7F 


SS Version 


SS Version 
Indicator 


11.5.4.24 





TLV 


2-3 



10.3.1.2.1 Facility 

This information element may be used for functional operation of supplementary services. It will not be sent by the 
MES (no supplementary services supported in the Network require to send it). If received by the Network, a FACEl^ITY 
message will be returned to the MES to reject the supplementary service invocation. 

10.3.1.2.2 User -User 

This information element will not be sent by the MES (user-to-user service not supported in the network) and will be 
ignored by the Network if received. 

10.3.1.2.3 SS version 

This information element shall not be included if the facility information element is not present in this message. If 
received without facility information element the call shall be released. 

This information element shall be included or excluded as defined in GSM 04.10 [17]. This information element should 
not be transmitted unless explicitly required by GSM 04.10 [17]. 

10.3.2 Call Confirmed 

This message is sent by the called MES to confirm an incoming call request. See table 10.3.2.1. 
Message Type: CALL CONFIRMED 
Significance: Local 
Direction: MES to Network 
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Table 10.3.2.1 : CALL CONFIRMED Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call Control Protocol Discriminator 


Protocol 
Discriminator 


11.2 


M 


V 


1/2 




Transaction Identifier 


Transaction 
Identifier 


11.3.2 


M 


V 


1/2 




Call Confirmed Message Type 


Message Type 


11.4 


M 


V 


1 


D- 


Repeat Indicator 


Repeat Indicator 


11.5.4.22 


C 


TV 


1 


04 


Bearer Capability 1 


Bearer Capability 


11.5.4.5 





TLV 


3-10 


04 


Bearer Capability 2 


Bearer Capability 


11.5.4.5 





TLV 


3-10 


08 


Cause 


Cause 


11.5.4.11 





TLV 


4-32 


15 


CO Capabilities 


Call Control 


11.5.4.5a 





TLV 


3 



10.3.2.1 Repeat indicator 

The repeat indicator information element shall not be included as only bearer capabihty 1 information element is 
included in the message. 

1 0.3.2.2 Bearer capability 1 and bearer capability 2 

The bearer capability 1 information element shall be included if and only if at least one of the following cases holds: 

The MES wishes another bearer capability than that given by the bearer capability 1 information element of the 
incoming SETUP message; 

The bearer capability 1 information element is not fully specified in the SETUP message. 

Refer to clause 6.2.2.3.2 for handling of bearer capabihty 1 information element by the Network. The bearer capabihty 
2 information element shall not be included. 

10.3.2.3 Cause 

This information element is included if the MES is compatible but the user is busy. It will be ignored by the network. 

10.3.2.4 CC Capabilities 

This information element will not be sent by the MES and will be ignored by the network if received. 

10.3.3 Call proceeding 

This message is sent by the Network to the calling MES to indicate that the requested call establishment information has 
been received, and no more call establishment information will be accepted. See table 10.3.3.1. 

Message Type: CALL PROCEEDING 

Significance: Local 

Direction: Network to MES 
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Table 10.3.3.1: CALL PROCEEDING Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Odll OUIILIUI rlULUOUl LyloOI II 1 MI IclLUI 


r lUlULfUl 

Discriminator 


1 1 


IVI 


\/ 

V 


1 /? 




Transaction Identifier 


Transaction 

IHpntif ipr 


11.3.2 


M 


V 


1/2 




Call Proceeding Message Type 


Message Type 


11.4 


M 


V 


1 


D- 


Repeat Indicator 


Repeat Indicator 


11.5.4.22 


C 


TV 


1 


04 


Bearer Capability 1 


Bearer Capability 


11.5.4.5 





TLV 


3-10 


04 


Bearer Capability 2 


Bearer Capability 


11.5.4.5 





TLV 


3-10 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


1E 


Progress Indicator 


Progress Indicator 


11.5.4.21 





TLV 


4 



10.3.3.1 Repeat indicator 

This information element shall not be included in the message. 

1 0.3.3.2 Bearer capability 1 and bearer capability 2 

The bearer capability 1 information element is always included. The network may specify at least one of the negotiable 
parameters described in GSM 07.01 [28]. 

The bearer capability 2 information element shall not be included. 

10.3.3.3 Facility 

This information element may be used for functional operation of supplementary services. It will not be sent by the 
network (no supplementary services supported in the Network require to send it). 

10.3.3.4 Progress indicator 

This information element will not be included 

10.3.4 Congestion control 

This message is sent by the MES or the network to indicate the estabUshment or termination of flow control on the 
transmission of USER INFORMATION messages. 

User-to-user service being not supported in the network, this message shall not be sent by the MES nor by the Network 
and shall be ignored if received. See table 10.3.4.1. 

Message Type: CONGESTION CONTROL 

Significance: Local (see note) 

Direction: Both 
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Table 10.3.4.1 : CONGESTION CONTROL Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
ril^irrlmlnatnr 

\A II 1 III 1 CiLWI 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Congestion control 
message type 


Message Type 


11.4 


M 


V 


1 




Congestion level 


Congestion level 


11.5.4.12 


M 


V 


1/2 




Spare half octet 


Spare half octet 


11.5.1.8 


M 


V 


1/2 


08 


Cause 


Cause 


11.5.4.11 





TLV 


4-32 



NOTE: This message has local significance, but may carry information of global significance. 

10.3.4.1 Cause 

This information element is included if the user to user information has been discarded as a result of the congestion 
situation. 

10.3.5 Connect 

1 0.3.5.1 Connect (Network to MES direction) 

This message is sent by the network to the calling MES to indicate call acceptance by the called user. See table 10.3.5.1. 
Message Type: CONNECT 
Significance: Global 
Direction: Network to MES 



Table 10.3.5.1 : CONNECT Message Content (network to MES direction) 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 

discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Connect message type 


Message Type 


11.4 


M 


V 


1 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


1E 


Progress Indicator 


Progress Indicator 


11.5.4.21 





TLV 


4 


4C 


Connected number 


Connected number 


11.5.4.13 





TLV 


3-14 


4D 


Connected subaddress 


Connected 
subaddress 


11.5.4.14 





TLV 


3-23 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 



10.3.5.1.1 Facility 

This information element may be used for functional operation of supplementary services. It will not be sent by the 
Network (no supplementary services supported in the Network require to send it). 

1 0.3.5.1 .2 Progress indicator 

This information element may be included by the Network: 

In order to pass information about the call in progress, e.g., in the event of interworking; and/or 
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To make the MES attach the user connection for speech. 
Refer to clause 6.2.1.4 for the possible values sent by the MSC. 

10.3.5.1.3 User-User 

This information element will not be sent (user-to-user service not supported in the network). 
10.3.5.2 Connect (MES to Network direction) 

This message is sent by the called MES to the network to indicate call acceptance by the called user. See table 10.3.5.2 
Message Type: CONNECT 
Significance: Global 
Direction: MES to Network 



Table 10.3.5.1 : CONNECT Message Content (MES to network direction) 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 

discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Connect message type 


Message Type 


11.4 


M 


V 


1 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


4D 


Connected subaddress 


Connected 
subaddress 


11.5.4.14 





TLV 


3-23 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 


7F 


SS version 


SS version indicator 


1 1 .5.4.24 





TLV 


2-3 



10.3.5.2.1 Facility 

This information element may be used for functional operation of supplementary services. It will not be sent by the 
MES (no supplementary services supported in the network require to send it). If received by the Network, a FACILITY 
message will be returned to the MES to reject the supplementary service invocation. 

10.3.5.2.2 User-User 

This information element will not be sent by the MES (user-to-user service not supported in the network) and will be 
ignored by the network if received. 

10.3.5.2.3 SS version 

This information element shall not be included if the facility information element is not present in this message. If 
received without a facility information element, the call shall be released. 

This information element shall be included or excluded as defined in GSM 04.10 [17]. This information element should 
not be transmitted unless explicitly required by GSM 04.10 [17]. 

10.3.6 Connect acknowledge 

This message is sent by the network to the called MES to indicate that the MES has been awarded the call. It shall also 
be sent by the calling MES to the network to acknowledge the offered connection. See table 10.3.6.1. 

Message Type: CONNECT ACKNOWLEDGE 

Significance: Local 

Direction: Both 
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Table 10.3.6.1 : CONNECT ACKNOWLEDGE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Connect acl^nowledge message 
type 


Message Type 


11.4 


M 


V 


1 



10.3.7 Disconnect 

1 0.3.7.1 Disconnect (Network to MES direction) 

This message is sent by the network to indicate that the end-to-end connection is cleared. See table 10.3.7.1. 
Message Type: DISCONNECT 
Significance: Global 
Direction: Network to MES 



Table 10.3.7.1 : DISCONNECT Message Content (network to MES direction) 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 

identifier 


11.3.2 


M 


V 


1/2 




Disconnect message type 


Message Type 


11.4 


M 


V 


1 




Cause 


Cause 


11.5.4.11 


M 


LV 


3-31 


1C 


Facility 


Facility 


11.5.4.15 


O 


TLV 


2-1 


IE 


Progress indicator 


Connected 
subaddress 


11.5.4.21 





TLV 


4 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 



10.3.7.1.1 Facility 

This information element may be used for functional operation of supplementary services. It will not be sent by the 
Network (no supplementary services supported in the Network require to send it). 

10.3.7.1.2 Progress indicator 

This information element may be included by the Network: 

10.3.7.1.3 User-User 

This information element will not be sent (user-to-user service not supported in the network). 

1 0.3.7.2 Disconnect (MES to Network direction) 

This message is sent by the MES to request the network to clear an end-to-end connection. This message shall not be 
sent by the MES if the call to be released is a MES-to-MES single hop call. See table 10.3.7.2. 

Message Type: DISCONNECT 

Significance: Global 

Direction: MES to Network 
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Table 10.3.7.2: DISCONNECT Message Content (MES to Network direction) 



IPI 

Id 


inior iTiciuon dciricni 


Type 






rorniai 


Lcnyin 




Call rnntrni nrntnrni rli<^priminatnr 


Prntnrnl 
discriminator 


1 1 .2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Disconnect message type 


Message Type 


11.4 


M 


V 


1 




Cause 


Cause 


11.5.4.11 


M 


LV 


3-31 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 


7F 


SS version 


SS version indicator 


1 1 .5.4.24 





TLV 


2-3 



10.3.7.2.1 Facility 

This information element may be used for functional operation of supplementary services, such as the user-user service. 
It will not be sent by the MES (no supplementary services supported in the Network require to send it). If received by 
the Network, a FACILITY message will be returned to the MES to reject the supplementary service invocation. 

10.3.7.2.2 User-User 

This information element will not be sent by the MES (user-to-user service not supported in the Network) and will be 
ignored by the Network if received. 

10.3.7.2.3 SS version 

This information element shall not be included if the facility information element is not present in this message. If 
received without facility information element the call shall be released. 

This information element shall be included or excluded as defined in GSM 04.10 [17]. This information element should 
not be transmitted unless explicitly required by GSM 04.10 [17]. 

10.3.8 Emergency setup 

This message is sent trom the MES to initiate emergency call establishment. See table 10.3.8.1. 
Message Type: EMERGENCY SETUP 
Significance: Global 
Direction: MES to Network 



Table 10.3.8.1 : EMERGENCY SETUP Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Emergency setup message type 


Message Type 


11.4 


M 


V 


1 


04 


Bearer capability 


Bearer capability 


11.5.4.5 





TLV 


3 



10.3.8.1 Bearer capability 

If the element is not included, the network shall by default assume speech and select full rate speech. If this information 
element is included, it shall indicate speech with the appropriate value radio channel requirement field. 
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10.3.9 Facility 

1 0.3.9.1 Facility (Network to MES direction) 

This message is sent by the network to the MES to request or acknowledge a supplementary service. The supplementary 
service to be invoked and its associated parameters are specified in the facility information element. See table 10.3.9.1. 

Message Type: FACILITY 

Significance: Local (Note 1) 

Direction: Network to MES 



Table 10.3.9.1 : FACILITY Message Content (Network to MES direction) 



lEI 


information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 

identifier 


11.3.2 


M 


V 


1/2 




Facility message type 


Message Type 


11.4 


M 


V 


1 




Facility (note 2) 


Facility 


11.5.4.15 


M 


LV 


1-? 



NOTE 1: This message has local significance, however, it may carry information of global significance. 

NOTE 2: The facility information element has no upper length limit except that given by the maximum number of 
octets in a L3 message, see GMR-2 04.006 [15]. 

1 0.3.9.2 Facility (MES to Network direction) 

This message is sent by the MES to the network to request or acknowledge a supplementary service. The supplementary 
service to be invoked and its associated parameters are specified in the facility information element. See table 10.3.9.2. 

Message Type: FACILITY 

Significance: Local (Note 1) 

Direction: MES to Network 



Table 10.3.9.2: FACILITY Message Content (MES to Network direction) 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 

discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Facility message type 


Message Type 


11.4 


M 


V 


1 




Facility (Note 2) 


Facility 


11.5.4.15 


M 


LV 


1-? 


7F 


SS version 


SS version indicator 


1 1 .5.4.24 





TLV 


2-3 



NOTE 1 : This message has local significance; however, it may carry information of global significance. 

NOTE 2: The facility information element has no upper length limit except that given by the maximum number of 
octets in a L3 message, see GMR-2 04.006 [15]. 

10.3.9.2.1 SS version 

This information element shall be included or excluded as defined in GSM 04.10 [17]. This information element should 
not be transmitted unless explicitly required by GSM 04.10 [17]. If received without facihty information element the 
call shall be released. 
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10.3.10 Hold 

This message is sent by the mobile user to request the hold function for an existing call. 

This message shall not be sent by the MES if the existing call to be put on hold is a single hop MES-to-MES call. See 
table 10.3.10.1 for the content of the HOLD message. 

For the use of this message, see GSM 04.10 [17]. 

Message Type: HOLD 

Significance: Local 

Direction: MES to Network 



Table 10.3.10.1 : HOLD Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Hold message type 


Message Type 


11.4 


M 


V 


1 



1 0.3.1 1 Hold acknowledge 

This message is sent by the network to indicate that the hold function has been successfully performed. See table 
10.3.11.1 for the content of the HOLD ACKNOWLEDGE message. 

For the use of this message, see GSM 04.10 [17]. 

Message Type: HOLD ACKNOWLEDGE 

Significance: Local 

Direction: Network to MES 



Table 10.3.11.1 : HOLD ACKNOWLEDGE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Hold Acknowledge message type 


Message Type 


11.4 


M 


V 


1 



10.3.12 Hold reject 

This message is sent by the network to indicate the denial of a request to hold a call. See table 10.3. 12. 1 for the content 
of the HOLD REJECT message. 

For the use of this message, see GSM 04.10 [17]. 

Message Type: HOLD REJECT 

Significance: Local 

Direction: Network to MES 
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Table 10.3.12.1 : HOLD ACKNOWLEDGE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Hold Reject message type 


Message Type 


11.4 


M 


V 


1 




Cause 


Cause 


11.5.4.11 


M 


LV 


3-31 



10.3.13 Modify 

This message is sent by the MES to the network or by the network to the MES to request a change in bearer capability 
for a call. 

As change of bearer capability for a call is not supported in the network (refer to SETUP description in clause 10.3.23), 
this message shall not be sent by the MES nor by the Network and shall be ignored if received. See table 10.3.13.1. 

Message Type: MODIFY 

Significance: Global 

Direction: Both 



Table 10.3.13.1 : MODIFY Message Content 



lEI 


information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 

identifier 


11.3.2 


M 


V 


1/2 




Modify message type 


Message Type 


11.4 


M 


V 


1 




Bearer capability 


Bearer capability 


11.5.4.5 


M 


LV 


2-9 


7C 


Low layer comp 


Low layer comp. 


11.5.4.18 





TLV 


2-15 


7D 


High layer comp 


High layer comp 


11.5.4.16 





TLV 


2-5 


A3 


Reverse call setup direction 


Reverse call setup 
direction 


1 1 .5.4.22a 





T 


1 



1 0.3.1 3.1 Low layer compatibility 

This information element shall be included if it was included in the initial SETUP message. 

1 0.3. 1 3.2 High layer compatibility 

This information element shall be included if it was included in the initial SETUP message 

10.3.13.3 Reverse call setup direction 

This information element is included or omitted in the MES to Network direction according to the rules defined in 
clause 6.3.4.3.1. 

10.3.14 Modify complete 

This message is sent by the MES to the network or by the network to the MES to indicate completion of a request to 
change bearer capability for a call. 

As change of bearer capability for a call is not supported in the network (refer to SETUP description in clause 10.3.23), 
this message shall not be sent by the MES nor by the Network and shall be ignored if received. See table 10.3.14.1. 
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Message Type: MODIFY COMPLETE 
Significance: Global 
Direction: Both 



Table 10.3.14.1 : MODIFY COMPLETE Message Content 



IE! 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 

identifier 


11.3.2 


M 


V 


1/2 




Modify complete message type 


Message Type 


11.4 


M 


V 


1 




Bearer capability 


Bearer capability 


11.5.4.5 


M 


LV 


2-9 


7C 


Low layer comp 


Low layer comp 


11.5.4.18 


O 


TLV 


2-15 


7D 


High layer comp 


High layer comp 


11.5.4.16 





TLV 


2-5 



1 0.3.1 4.1 Low layer compatibility 

This information element shall be included if it was included in the initial SETUP message. 

10.3.14.2 High layer compatibility 

This information element shall be included if it was included in the initial SETUP message. 

10.3.14.3 Reverse call setup direction 

This information element is included or omitted according to the rules defined in clause 6.3.4.3.2. 

10.3.15 Modify reject 

This message is sent by the MES to the network or by the network to the MES to indicate failure of a request to change 
the bearer capability for a call. See table 10.3.15.1. 

As change of bearer capability for a call is not supported in the network (refer to SETUP description in clause 10.3.23), 
this message shall not be sent by the MES nor by the Network and shall be ignored if received. 

Message Type: MODIFY REJECT 

Significance: Global 

Direction: Both 

Table 10.3.15.1 : MODIFY REJECT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 

identifier 


11.3.2 


M 


V 


1/2 




Modify reject message type 


Message Type 


11.4 


M 


V 


1 




Bearer capability 


Bearer capability 


11.5.4.5 


M 


LV 


2-9 




Cause 


Cause 


11.5.4.11 


M 


LV 


3-31 


7C 


Low layer comp 


Low layer comp. 


11.5.4.18 





TLV 


2-15 


7D 


High layer comp 


High layer comp 


11.5.4.16 





TLV 


2-5 



10.3.15.1 Low layer compatibility 

This information element shall be included if it was included in the initial SETUP message. 
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1 0.3. 1 5.2 High layer compatibility 

This information element shall be included if it was included in the initial SETUP message. 

10.3.16 Notify 

This message is sent either from the MES or from the network to indicate information pertaining to a call, such as user 
suspended. See table 10.3.16.1. 

As user notification procedure is not required in the network (refer to clause 6.3. 1), this message shall not be sent by the 
MES nor by the Network and shall be ignored if received. 

Message Type: NOTIFY 

Significance: Access 

Direction: Both 



Table 10.3.16.1 : NOTIFY Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Notify message type 


Message Type 


11.4 


M 


V 


1 




Notification Indicator 


Notification Indicator 


1 1 .5.4.20 


M 


V 


1 



10.3.17 Progress 

This message is sent from the network to the MES to indicate the progress of a call in the event of interworking or in 
connection with the provision of in-band information/patter. See table 10.3.17.1. 

Refer to clause 6.2.1.4 and 6.5.1 for sending of this message. Possible values of the progress indicator information 
element are #1 and #8. 

Message type: PROGRESS 

Significance: Global 

Direction: Network to MES 



Table 10.3.17.1 : PROGRESS Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Progress message type 


Message Type 


11.4 


M 


V 


1 




Progress Indicator 


Notification Indicator 


11.5.4.21 


M 


LV 


3 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 



10.3.17.1 User-user 

This information element will not be sent (user-to-user service not supported in the network). 
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10.3.18 Release 

1 0.3.1 8.1 Release (Network to MES direction) 

This message is sent, from the network to the MES to indicate that the network intends to release the transaction 
identifier, and that the receiving equipment shall release the transaction identifier after sending RELEASE 
COMPLETE. See table 10.3.18.1. 

Message Type: RELEASE 

Significance: Local (see Note) 

Direction: Network to MES 



Table 10.3.18.1 : RELEASE Message Content (Network to MES direction) 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


U 


V 


1/2 




Release message type 


Message Type 


11.4 


M 


V 


1 


08 


Cause 


Cause 


11.5.4.11 





TLV 


4-32 


08 


Second cause 


Cause 


11.5.4.11 





TLV 


4-32 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 



NOTE: This message has local significance, however, it may carry information of global significance when used 
as the first caU clearing message. 

10.3.18.1.1 Cause 

This information element shall be included if this message is used to initiate call clearing. It will also be included when 
this message is sent after expiration of timer T305 (no RELEASE message received in response to a DISCONNECT 
message sent to the MES). The cause value will be the cause value originally contained in that DISCONNECT 
message. 

1 0.3.1 8.1 .2 Second cause 

This information element will never be sent by the network. 

10.3.18.1.3 Facility 

This information element may be included for functional operation of supplementary services. It will not be sent by the 
Network (no supplementary services supported in the Network are required to send it). 

10.3.18.1.4 User-user 

This information element will not be sent (user-to-user service not supported in the network). 

1 0.3.1 8.2 Release (MES to Network direction) 

This message is sent from the MES to the network to indicate that the MES intends to release the transaction identifier, 
and that the receiving equipment shall release the transaction identifier after sending RELEASE COMPLETE. See table 
10.3.18.2. 

In the case of MES-to-MES single hop call, this message is sent by the MES which initiates the call clearing (no 
DISCONNECT message sent). In that case, the RELEASE message shall not be sent to the MSC. It shall be handled by 
the GSC (refer to clause 8.3.4 for MES-to-MES call clearing). 
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Message Type: RELEASE 
Significance: Local (Note) 
Direction: MES to Network 



Table 10.3.18.2: RELEASE Message Content (MES to Network direction) 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 

identifier 


11.3.2 


M 


V 


1/2 




Release message type 


Message Type 


11.4 


M 


V 


1 


08 


Cause 


Cause 


11.5.4.11 





TLV 


4-32 


08 


Second cause 


Cause 


11.5.4.11 


O 


TLV 


4-32 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


7E 


User-user 


User-user 


11.5.4.25 





TLV 


3-35 


7F 


SS version 


SS version indicator 


1 1 .5.4.24 





TLV 


2-3 



NOTE: This message has local significance, however, it may carry information of global significance when used 
as the first call clearing message. 

10.3.18.2.1 Cause 

This information element shall be included if this message is used to initiate call clearing. 

1 0.3.1 8.2.2 Second cause 

This information element will never be sent by the MES. 

10.3.18.2.3 Facility 

This information element may be included for functional operation of supplementary services. It will not be sent by the 
MES (no supplementary services supported in the Network require to send it). If received by the Network, a FACILITY 
message will be returned to the MES to reject the supplementary service invocation. 



10.3.18.2.4 



User-user 



This information element will not be sent by the MES (user-to-user service not supported in the Network) and will be 
ignored by the Network if received. 

10.3.18.2.5 SS version 

This information element shall not be included if the facility information element is not present in this message. 

This information element shall be included or excluded as defined in GSM 04.10 [17]. This information element should 
not be transmitted unless explicitly required by GSM 04.10 [17]. 

1 0.3.1 8.3 Release (MES to MES) 

This message is sent from the MES to another MES in the case of a direct mobile-to-mobile call, to indicate that one of 
the MESs intends to release the traffic chaimel, terminate the call and return to idle, and that the receiving MES shaU 
release the traffic channel, terminate the call and return to idle after sending RELEASE COMPLETE. See table 
10.3.18.3. 

Message Type: RELEASE 
Significance: Local (Note) 
Direction: MES to MES 
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Table 10.3.18.3: RELEASE Message Content (MES to MES) 



IPI 

Id 


inior iTiciuon dciricni 


Type 






rorniai 


Lcnyin 




Call rnntrni nrntnrni rli<^priminatnr 


Prntnrnl 
discriminator 


1 1 .2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Release message type 


Message Type 


11.4 


M 


V 


1 


08 


Cause 


Cause 


11.5.4.11 





TLV 


4-32 


08 


Second cause 


Cause 


11.5.4.11 





TLV 


4-32 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 



10.3.18.3.1 Cause 

This information element may be included under the conditions described in clause 6.4.3.5 "Abnormal cases" (Clearing 
initiated by the MES). In a vaUd Release, this shall be set to "MES to MES CC release". 

1 0.3.1 9 Release complete 

10.3.19.1 Release complete (Network to MES direction) 

This message is sent trom the network to the MES to indicate that the network has released the transaction identitier 
and that the User Terminal shall release the transaction identifier. See table 10.3.19.1. 

Message Type: RELEASE COMPLETE 

Significance: Local (Note) 

Direction: Network to MES direction 



Table 10.3.19.1 : RELEASE COMPLETE Message Content (Network to MES direction) 



IE! 


information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 

discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Release complete message type 


Message Type 


11.4 


M 


V 


1 


08 


Cause 


Cause 


11.5.4.11 





TLV 


4-32 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 



NOTE: This message has local significance, however, it may carry information of global significance when used 
as the first call clearing message. 

10.3.19.1.1 Cause 

This information element shall be included if the message is used to initiate call clearing. 

10.3.19.1.2 Facility 

This information element may be included for functional operation of supplementary services, e.g., it is sent by the 
network to notify the calling subscriber that the call is barred (message sent in response to SETUP). 

10.3.19.1.3 User-user 

This information element will not be sent (user-to-user service not supported in the Network). 
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10.3.19.2 Release complete (MES to Network direction) 

This message is sent from the MES to the network to indicate that the MES has released the ttansaction identifier and 
that the network shall release the ttansaction identifier. See table 10.3.19.2. 

Message Type: RELEASE COMPLETE 

Significance: Local (Note) 

Direction: MES to Network direction 



Table 10.3.19.2: RELEASE COMPLETE Message Content (MES to Network direction) 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 

identifier 


11.3.2 


M 


V 


1/2 




Release complete message type 


Message Type 


11.4 


M 


V 


1 


08 


Cause 


Cause 


11.5.4.11 





TLV 


4-32 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-1 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 


7F 


SS version 


SS Version indicator 


1 1 .5.4.24 





TLV 


2-3 



NOTE: This message has local significance; however, it may carry information of global significance when used 
as the first call clearing message. 

10.3.19.2.1 Cause 

This information element shall be included if the message is used to initiate call clearing. 

10.3.19.2.2 Facility 

This information element may be included for fiinctional operation of supplementary services. It will not be sent by the 
MES (no supplementary services supported in the Network require to send it). If received by the Network, it will be 
ignored (no possibility to reply). 

10.3.19.2.3 User-user 

This information element will not be sent by the MES (user-to-user service not supported in the Network) and will be 
ignored by the Network if received. 

10.3.19.2.4 SS version. 

This information element shall not be included if the facility information element is not present in this message. 

This information element shall be included or excluded as defined in GSM 04.10 [17]. This information element should 
not be ttansmitted tinless explicitly required by GSM 04.10 [17]. 

1 0.3. 1 9.3 Release complete (MES to MES and Network) 

This message is sent from the MES directly to another MES in the case of a mobile-to-mobile call to indicate that the 
MES has released the ttaffic channel, terminated the call and return to idle. This S-FACCH command will force the 
network to teardown the call. See table 10.3.19.3. 

Message Type: RELEASE COMPLETE 

Significance: Local (Note) 

Direction: MES to MES and Network direction 
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Table 10.3.19.3: RELEASE COMPLETE Message Content (MES to MES and Network direction) 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Release complete message type 


Message Type 


11.4 


M 


V 


1 


08 


Cause 


Cause 


11.5.4.11 





TLV 


4-32 



10.3.19.3.1 Cause 

This information element shall be included if the message is used to initiate call clearing. In a valid Release this shall be 
set to "MES to MES CC release". 

10.3.20 Retrieve 

This message is sent by the mobile user to request the retrieval of a held call. 

This message shall not be sent by the MES if the retrieve request is related to single hop MES-to-MES call. See table 
10.3.20.1 for the content of the RETRIEVE message. 

For the use of this message, see GSM 04.10 [17]. 

Message Type: RETRIEVE 
Significance; Local 
Direction: MES to Network 



Table 10.3.20.1: RETREIVE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Retrieve message type 


Message Type 


11.4 


M 


V 


1 



10.3.21 Retrieve acknowledge 

This message is sent by the network to indicate that the retrieve function has been successfully performed. See table 
10.3.21.1 for the content of the RETRIEVE ACKNOWLEDGE message. For the use of this message, see 
GSM 04.10 [17]. 

Message Type: RETRIEVE ACKNOWLEDGE 
Significance: Local 
Direction: Network to MES 



Table 10.3.21.1 : RETREIVE ACKNOWLEDGE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 

discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Retrieve Acknowledge message 
type 


Message Type 


11.4 


M 


V 


1 
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10.3.22 Retrieve reject 

This message is sent by the network to indicate the inability to perform the requested retrieve function. See able 
10.3.22.1 for the content of the RETRffiVE REJECT message. 

For the use of this message, see GSM 04.10 [17]. 

Message Type: RETRIEVE REJECT 

Significance: Local 

Direction: Network to MES 



Table: 10.3.22.1 : RETREIVE REJECT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Retrieve Reject message type 


Message Type 


11.4 


M 


V 


1 




Cause 


Cause 


11.5.4.11 


M 


LV 


3-31 



10.3.23 Setup 

10.3.23.1 Setup (mobile terminated call establishment) 

This message is sent by the network to the MES to initiate a mobile terminated call establishment. See table 10.3.23.1. 
Message Type: SETUP 
Significance: Global 
Direction: Network to MES 
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Table: 10.3.23.1 : SETUP Message Content (Network to MES direction) 





inTOiinaiion cismeni 


Type 


neTerence 


rresence 


rormai 


Lengin 




L/aii coniioi proiocol aiscnrninaior 


r roiocol 

UloLfl II 1 III icilUi 


1 1 .£L 


^/l 

IVI 


\/ 

V 






1 1 al IbdULIUi 1 lUci ILIIIci 


1 lallbclULIUil 

identifier 


1 1 .O.^ 


IVI 


\/ 

V 






Oc;lUp lllcbodyt: Lypc 


IVIcooayt: 1 ypt: 


1 1 .H- 


IVI 


\/ 

V 


■1 
1 


D- 


BC repeat indicator 


Repeat indicator 


11.5.4.22 


c 


TV 


1 




Dearer capaDiiiiy i 


Dearer capauiiiiy 


A A ^ A ^ 




1 LV 


Q 1 n 
o- 1 u 


04 


Bearer capability 2 


Bearer capability 


11.5.4.5 





TLV 


3-10 


\ O 


Facility 


Facility 


1 1 .13. 4. Its 




1 LV 




1E 


Progress indicator 


Progress indicator 


11.5.4.21 





TLV 


4 


34 


Signal 


Signal 


1 1 .5.4.23 


o 


"r\ / 

TV 


2 


5C 


Calling party BCD number 


Calling party BCD 
num. 


1 1 .5.4.9 


o 


Tl \ / 

TLV 


3-14 


Kn 
OU 


-— — — — — — — 

Calling party sub-address 


Calling party 

suDaoaress 


\ \ .0.4. ID 


U 


1 LV 


£.-£.■5 


ot 


L/aiieo parry dou numDer 


L/aiiea parry dou 
num . 


H H C /I "7 
1 1 .0.4. / 


u 


Tl \/ 
1 LV 


o-l o 


6D 


\_/c(ii\^u udi Ly OLJU cluui woo 


Callpri nartv 
subaddress 


11.5.4.8 





TLV 


2-23 


D- 


LLC repeat indicator 


Repeat indicator 


11.5.4.22 





TV 


1 


7C 


Low layer compatibility 1 


Low layer com p. 


11.5.4.18 





TLV 


2-15 


7C 


Low layer compatibility II 


Low layer com p. 


11.5.4.18 


C 


TLV 


2-15 


D- 


HLC repeat indicator 


Repeat indicator 


11.5.4.22 





TV 


1 


7D 


High layer compatibility i 


High layer comp. 


11.5.4.16 





TLV 


2-5 


7D 


Low layer compatibility ii 


High layer comp. 


11.5.4.16 


c 


TLV 


2-5 


7E 


User-user 


User-user 


1 1 .5.4.25 





TLV 


3-35 



1 0.3.23.1 .1 BC repeat indicator 

The BC repeat indicator information element is included if and only if bearer capability 1 information element and 
bearer capability 2 IE are both present in the message. 

1 0.3.23.1 .2 Bearer capability 1 and bearer capability 2 

The bearer capability 1 information element is always sent by the network (it corresponds to the GSM-BC information 
received from HLR at roaming number provision or implicitly to speech if this information was not received. The 
bearer capabiUty 2 IE is never sent. 

10.3.23.1.3 Facility 

This information element may be included for functional operation of supplementary services, e.g., it is sent by the 
Network in case of call forwarding (to notify the forwarded to party). 

1 0.3.23.1 .4 Progress indicator 

This information element is included by the network: 

In order to pass information about the call in progress, e.g., in the event of interworking; and/or 

To make the MES attach the user connection for speech. 
Possible values sent by the network are #1 and #3. 

1 0.3.23.1 .5 Called party subaddress 

Included in the Network-to-MES direction if the calling user includes a called party subaddress information element in 
the SETUP message. 
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1 0.3.23.1 .6 LLC repeat indicator 

The LLC repeat indicator information element is included if and only if both following conditions hold: 

The BC repeat indicator IE is contained in the message; 

The low layer compatibility / IE is contained in the message. 
The LLC repeat indicator IE will never be sent by the Network. 

1 0.3.23.1 .7 Low layer compatibility I 

Included in the network-to-MES direction if the calling user specified a low layer compatibility. 
The LLC 1 IE will never be sent by the Network. 

1 0.3.23.1 .8 Low layer compatibility II 

Included if and only if the LLC repeat indicator information element is contained in the message. 
The LLC 2 IE will never be sent by the Network. 

1 0.3.23.1 .9 HLC Repeat Indicator 

The HLC repeat indicator IE will never be sent by the Network. 

The HLC repeat indicator information element is included if and only both following conditions hold: 
The BC repeat indicator IE is contained in the message; 
The high layer compatibiUty IE is contained in the message. 

1 0.3.23.1 .1 High layer compatibility I 

Included in the network-to-MES direction if the calling user specified a high layer compatibility. 

The HLC I IE will be sent by the network if it has been previously received from the HLR at roaming number 
provision. 

1 0.3.23.1 .1 1 High layer compatibility II 

Included if and only if the HLC repeat indicator information element is contained in the message. 
The HLC II IE will never be sent by the network. 

10.3.23.1.12 User-user 

Not included (user-to-user service not supported in the network). 

10.3.23.1.13 Signal 

Sent by the network if the SETUP message is related to a call waiting invocation or to an operator intervention. Its 

possible values are: 

"call waiting tone on" (call waiting case); 
"intercept tone on" (operator intervention case). 
Otherwise, it is never sent by the network. 

1 0.3.23.1 .1 4 Calling party BCD number 

Not sent (CLIP supplementary service not required in the network). 
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1 0.3.23.1 .1 5 Calling party subaddress 

Not sent (CLIP supplementary service not required in network). 

1 0.3.23.1 .16 Called party BCD number 

Always included except in the case of a SETUP message for call waiting or operator intervention. 

10.3.23.2 Setup (mobile originating call establishment) 

This message is sent from the MES to the network to initiate a mobile originating call establishment. See table 
10.3.23.2. 

Message Type: SETUP 
Significance: Global 
Direction: MES to Network 



Table: 10.3.23.2: SETUP Message Content (MES to Network direction) 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Setup message type 


Message Type 


11.4 


M 


V 


1 


D- 


BC repeat indicator 


Repeat indicator 


11.5.4.22 


C 


TV 


1 


04 


Bearer capability 1 


Bearer capability 


11.5.4.5 


M 


TLV 


3-10 


04 


Bearer capability 2 


Bearer capability 


11.5.4.5 





TLV 


3-10 


1C 


Facility 


Facility 


11.5.4.15 





TLV 


2-? 


5D 


Calling party sub- address 


Calling party 
subaddr- 


11.5.4.10 





TLV 


2-23 


5E 


Called party BCD number 


Called party BCD 
num. 


11.5.4.7 


M 


TLV 


3-13 


6D 


Called party sub- address 


Called party 

subaddr. 


11.5.4.8 





TLV 


2-23 


D- 


LLC repeat indicator 


Repeat indicator 


11.5.4.22 





TV 


1 


7C 


Low layer compatibility 1 


Low layer com p. 


11.5.4.18 


o 


TLV 


2-15 


7C 


Low layer compatibility II 


Low layer comp. 


11.5.4.18 


c 


TLV 


2-15 


D- 


HLC repeat indicator 


Repeat indicator 


11.5.4.22 





TV 


1 


7D 


High layer compatibility i 


High layer comp. 


11.5.4.18 





TLV 


2-5 


7D 


Low layer compatibility ii 


High layer comp. 


11.5.4.18 


c 


TLV 


2-5 


7E 


User-user 


User-user 


11.5.4.25 





TLV 


3-35 


7F 


SS version 


SS version indicator 


11.5.4.24 





TLV 


2-3 


A1 


CLIR suppression 


CLIR suppression 


11.5.4.11a 


G 


T 


1 


A2 


CLIR invocation 


CLIR invocation 


11.5.4.11b 


C 


T 


1 


15 


CC Capabilities 


Call Control 


11.5.4.5a 





TLV 


3 



1 0.3.23.2.1 BC repeat indicator 

The BC repeat indicator information element is included if and only if bearer capability 1 IE and bearer capabiUty 2 IE 
are both present in the message. 

10.3.23.2.2 Facility 

The information element may be included for functional operation of supplementary services. It will not be sent by the 
MES (no supplementary services supported in the Network require to send it). If received by the network, a FACILITY 
message will be returned to the MES to reject the supplementary service invocation. 
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10.3.23.2.3 



LLC repeat indicator 



The LLC repeat indicator information element is included if and only if both following conditions hold: 



The BC repeat indicator IE is contained in the message; 



The low layer compatibility I IE is contained in the message. 



The LLC repeat indicator IE will never be sent by the MES. 



10.3.23.2.4 



Low layer compatibility I 



The information element is included in the MES-to-network direction when the calling MES wants to pass low layer 
compatibility information to the called user. 

If this information element consists of more than 15 octets, octets 4a and 4b are discarded by the network before 
sending it to the called party. 



Included if and only if the LLC repeat indicator information element is contained in the message. 
The LLC H IE will never be sent by the MES. 

1 0.3.23.2.6 HLC Repeat Indicator 

The HLC repeat indicator information element is included if and only if both following conditions hold: 

The BC repeat indicator IE is contained in the message; 

The high layer compatibility I IE is contained in the message. 
The HLC II repeat indicator IE will never be sent by the MES. 

1 0.3.23.2.7 High layer compatibility I 

The information element is included when the calling MES wants to pass high layer compatibiUty information to the 
called user. 

1 0.3.23.2.8 High layer compatibility II 

Included if and only if the HLC repeat indicator information element is contained in the message. 
The HLC II IE will never be sent by the MES. 

10.3.23.2.9 User-user 

The information element wdU not be included (user-to-user service not supported in the network) and will be ignored by 
the Network if received. 

10.3.23.2.10 SS version 

This information element shall not be included if the facility information element is not present in this message. If 
received without facility information element the call shall be released. 

This information element shall be included or excluded as defined in GSM 04.10 [17]. This information element should 
not be transmitted unless explicitly required by GSM 04.10 [17]. 

10.3.23.2.11 CLIP suppression 

The information element may be included by the MES (see GSM 04.81 [20]). If this information element is included the 
CLIR invocation IE shall not be included. 



10.3.23.2.5 



Low layer compatibility II 
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It will not be sent by the MES (CLIR supplementary services not required in the network) 

10.3.23.2.12 CLIR invocation 

The information element may be included by the MES (see GSM 04.81 [20]). If this information element is included the 
CLIR suppression IE shall not be included. 

It will not be sent by the MES (CLIR supplementary services not required in the network) 

10.3.23.2.13 Bearer capability 2 

The bearer capability 2 IE shall never be sent by the MES (the only case where it would be accepted by the network is 
when one of the BC indicates speech and the other indicates facsimile group 3 which is not required in the network. 

1 0.3.23.2.1 4 Calling party subaddress 

May be included by the MES. The network will pass it to the called party if received. 

1 0.3.23.2.1 5 Called party subaddress 

May be included by the MES. The network will pass it to the called party if received. 

1 0.3.23.2.1 6 CC capabilities 

This information element may be included by the MES to indicate its call control capabihties. If this information 
element is sent by the MES, Hie network will ignore it. 

10.3.24 Start DTMF 

This message is sent by the MES to the Network and contains the digit the network should reconvert back into a DTMF 
tone which is then applied towards the remote user. This message is also sent by a MES to another MES in the case of a 
mobile to mobile call. See table 10.3.24.1. 

Message Type: START DTMF 

Significance: Local 

Direction: MES to Network or MES to MES 



Table: 10.3.24.1: START DTMF Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Start DTMF message type 


Message Type 


11.4 


M 


V 


1 


2C 


Keypad facility 


Keypad facility 


11.5.4.17 


M 


TV 


2 



10.3.25 Start DTMF acknowledge 

This message is sent by the network to the MES to indicate the successful initiation of the action requested by the 
START DTMF message (conversion of the digit contained in this message into a DTMF tone). See table 10.3.25.1. 

Message Type: START DTMF ACKNOWLEDGE 

Significance: Local 

Direction: Network to MES or MES to another MES 
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Table: 10.3.25.1 : START DTMF ACKNOWLEDGE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Start DTMF acl<nowledge message 
type 


Message Type 


11.4 


M 


V 


1 


2C 


Keypad facility 


Keypad facility 


11.5.4.17 


M 


TV 


2 



10.3.25.1 Keypad facility 

This information element contains the digit corresponding to the DTMF tone that the network applies towards the 
remote user. 

10.3.26 Start DTMF reject 

This message is sent by the network to the MES, if the network can not accept the START DTMF message. See table 
10.3.26.1. 

Message Type: START DTMF REJECT 
Significance: Local 

Direction: Network to MES or MES to MES 



Table 10.3.26.1 : START DTMF REJECT Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 

identifier 


11.3.2 


M 


V 


1/2 




Start DTMF reject message type 


Message Type 


11.4 


M 


V 


1 




Cause 


Cause 


11.5.4.11 


M 


LV 


3-31 



10.3.27 Status 

This message is sent by the MES or the network at any time during a call to report certain error conditions listed in 
clause 9. It shall also be sent in response to a STATUS ENQUIRY message. See table 10.3.27.1. 

Message Type: STATUS 

Significance: Local 

Direction: Both 



Table: 10.3.27.1 : STATUS Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Status message type 


Message Type 


11.4 


M 


V 


1 




Cause 


Cause 


11.5.4.11 


M 


LV 


3-31 




Call state 


Call state 


11.5.4.6 


M 


V 


1 


24 


Auxiliary states 


Auxiliary states 


11.5.4.4 





TLV 


3 
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10.3.27.1 Auxiliary states 

The information element is included if and only if the call state is "active" and any auxiliary state is different from 
"idle". For the definition of the auxiliary states see GMR-2 04.083 [21] and GMR-2 04.084 [22]. 

10.3.28 Status enquiry 

This message is sent by the MES or the network at any time to solicit a STATUS message from the peer layer 3 entity. 
Sending of STATUS message in response to a STATUS ENQUIRY message is mandatory. See table 10.3.28.1. 

Message Type: STATUS ENQUIRY 

Significance: Local 

Direction: Both 



Table 10.3.28.1 : STATUS ENQUIRY Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Status enquiry message type 


Message Type 


11.4 


M 


V 


1 



10.3.29 StopDTMF 

This message is sent by a MES to the network and is used to stop the DTMF tone sent towards the remote user. See 
table 10.3.29.1. 

Message Type: STOP DTMF 
Significance: Local 

Direction: MES to Network or MES to MES 



Table 10.3.29.1 : STOP DTMF Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Stop DTIVIF message type 


Message Type 


11.4 


M 


V 


1 



10.3.30 Stop DTMF acknowledge 

This message shall be ignored if received by the network. See table 10.3.30.1. 

When applicable, this message is sent by the network to the MES to indicate that the sending of the DTMF tone has 
been stopped. 

Message Type: STOP DTMF ACKNOWLEDGE 
Significance: Local 

Direction: Network to MES or MES to MES 
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Table 10.3.30.1 : STOP DTMF ACKNOWLEDGE Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 
identifier 


11.3.2 


M 


V 


1/2 




Stop DTIVIF acl^nowledge message 
type 


Message Type 


11.4 


M 


V 


1 



10.3.31 User information 

This message shall not be sent by the user terminal nor by the network and shall be ignored if received (user-to-user 
service not supported in the network). 

When applicable, this message is sent by the MES to the network to transfer information to the remote user. This 
message is also sent by the network to the MES to deliver information transferred from the remote user. This message is 
used if the user-to-user transfer is part of an allowed information transfer as defined in GSM 04.10 [17]. See table 
10.3.31.1 

Message Type: USER INFORMATION 
Significance: Access 
Direction: Both 



Table 10.3.31.1: USER INFORMATION Message Content 



lEI 


Information Element 


Type 


Reference 


Presence 


Format 


Length 




Call control protocol discriminator 


Protocol 
discriminator 


11.2 


M 


V 


1/2 




Transaction identifier 


Transaction 

identifier 


11.3.2 


M 


V 


1/2 




User information message type 


Message Type 


11.4 


M 


V 


1 




User-user 


User-user 


11.5.4.25 


M 


LV 


3-130 


AO 


More data 


More data 


11.5.4.19 


O 


T 


1 



10.3.31.1 User-user 

Some networks may only support a maximum length of 35 octets. Procedures for interworking are not currently defined 
and are for further study. 

10.3.31.2 More data 

The information element is included by the sending user to indicate that another USER INFORMATION message 
pertaining to the same message block will follow. 
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1 1 General message format and information elements 
coding 

The figures and text in this clause describe the hiformation Elements (IE) contents. 

11.1 Overview 

Within the Layer 3 protocols defined in the present document, every message, with the exception of the messages sent 
on the S-BCCH, S-HBCCH, S-AGCH, S-PCH, S-HPACH, S-SCH and S-RACH, is a standard L3 message as defined 
in GMR-2 04.007 [16]. This means that the message consists of the following parts: 

a) Protocol discriminator; 

b) Transaction identifier; 

c) Message type; 

d) Other information elements, as required. 

This organization is illustrated in the example shown in figure 11.1.1. 



8 


7 6 5 


4 3 2 1 




Transaction Identifier 
or Skip Indicator 


Protocol Discriminator 


octet 1 




Message Type 


octet 2 


Other Information Elements As Required 


Etc... 



Figure 11.1.1: General message organization exampie 

Unless specified otherwise in the message descriptions of clause 10, a particular information element shall not be 
present more than once in a given message. 

The term "default" implies that the value defined shall be used in the absence of any assignment, or that this value 
allows negotiation of alternative values in between the two peer entities. 

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number 
increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet 
of the field. 



1 1 .2 Protocol Discriminator 

The Protocol Discriminator (PD) and its use are defined in GMR-2 04.007 [16]. This specification defines the protocols 
relating to the PD values 

Bits : 

4 3 2 1 

11 Call Control; Call Related SS Messages 

10 1 Mobility Management Messages 

110 Radio Resource Management Messages 



except the call related SS procedures, which are defined in GSM 04.10 [17]. 
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1 1 .3 Skip indicator and transaction identifier 

11.3.1 Si<ip indicator 

Bits 5 to 8 of the first octet of every Radio Resource management message and Mobility Management message contains 
the skip indicator. A message received with skip indicator different from 0000 shall be ignored. A message received 
with skip indicator encoded as 0000 shall not be ignored (unless it is ignored for other reasons). A protocol entity 
sending a Radio Resource management message or a Mobility Management message shall encode the skip indicator as 
0000. 

1 1 .3.2 Transaction identifier 

Bits 5 to 8 of the first octet of every message belonging to the protocol "Call Control; call related SS messages" contain 
the ttansaction identifier (TI). The ttansaction identifier and its use are defined in GMR-2 04.007 [16]. 

NOTE: Transaction K) may be ignored for single hop mobile-to-mobile calls. 

1 1 .4 IVIessage type 

The message type IE and its use are defined in GMR-2 04.007 [16]. Tables 11.4.1, 11.4.2, and 11.4.3 define the value 
part of the message type IE used in the Radio Resource management protocol, the Mobility Management protocol, and 
the Call Control protocol. 
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Table 11.4.1 : Message type for Radio Resource management 



o 
O 


—J 

7 


6 


5 


4 


3 


2 


1 










1 


1 


1 








Channel Establishment Messages: 















1 


1 


- Reserved 












1 


1 


1 


- Immediate Assignment 


















H 

1 


- Reserved 















1 





- Immediate Assignment Reject 








1 


1 





- 


- 


- 


Ciphering IVIessages: 












1 





1 


- Cipliering IVIode Command 















1 





- Cipliering Mode Complete 








1 





1 


- 


- 


- 


Handover Messages: 












1 


1 





- Assignment Command 


















1 


- Assignment Complete 












1 


1 


1 


- Assignment Failure 















1 


1 


- Reserved 












1 








- Reserved 





















- Reserved 












1 





1 


- Reserved 














1 


- 


- 


- 


Channel Release Messages: 












1 





1 


- Channel Release 















1 





- Reserved 












1 


1 


1 


- Reserved 








1 








_ 


_ 


_ 


Paging Messages: 


















1 


- Paging Request Type 1 















1 





- Reserved 












1 








- Reserved 












1 


1 


1 


- Paging Response 











1 


1 


- 


- 


- 


System Information Messages: 





















- System Information Type 8 


















1 


- Reserved 















1 





- System Information Type 2 















1 


1 


- System Information Type 3 


















1 














1 





1 


- System Information Type 5 












1 


1 





- System Information Type 6 












1 


1 


1 


- System Information Type 7 























System Information Messages: 















1 





- System Information Type 9 












1 





1 


- System Information Type 10 











1 











Miscellaneous Messages: 
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8 


7 6 


5 


4 


3 


2 


1 





















- Channel Mode Modify 













1 





- RR Status 










1 


1 


1 


- Channel Mode Modify Acknowledge 










1 


u 


u 


- Transmit Disable 
















1 


- Transmit Disable Ack 










1 





1 


- Measurement Report 










1 


1 





- Classmark Change 













1 


1 


- Classmark Enquiry 


tSis 


reserved for possible future use as an extension bit, se GMR-2 04.007 [16]. 










Table 11.4.2: Message types for Mobility Management 


8 


7 6 


5 


4 


3 


2 


1 







X 







- 


- 


- 


Registration IVIessages: 

















1 


- Reserved 














1 





- Location Updating Accept 











1 








- Location Updating Reject 








1 











- Location Updating Request 





X 


1 




- 


- 


- 


Security IVIessages: 

















1 


- Authentication Reject 














1 





- Authentication Request 











1 








- Authentication Response 








1 











- Identity Request 








1 








1 


- Identity Response 








1 





1 





- Reserved 








1 





1 


1 


- Reserved 





X 1 













Connection Management Messages: 

















1 


- CM Service Accept 














1 





- CM Service Reject 














1 


1 


- CM Service Abort 











1 








- CM Service Request 








1 











- Reserved 








1 








1 


- Reserved 
















Miscellaneous Messages: 





X 1 


1 










- Reserved 



Bit 8 is reserved for possible future use as an extension bit, see GMR-2 04.007 [16]. 

Bit 7 is reserved for the send sequence number in messages sent from the MES. In messages sent from the Network, bit 
7 is coded with a "0". See GMR-2 04.007 [16]. This bit may be ignored for single hop mobile-to-mobile signalling. 
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Table 11.4.3: Message Types for Call Control and Call related SS messages 



8 


7 


6 


5 


4 


3 


2 


1 







X 




















Escape To Nationally Specific Message Types; see note below 





X 








- 


- 


- 


- 


Call Establishment Messages: 



















1 


- Alerting 










1 











- Call Confirmed 
















1 





- Call Proceeding 













1 


1 


1 


- Connect 










1 


1 


1 


1 


- Connect Acknowledge 










1 


1 


1 





- Emergency Setup 
















1 


1 


- Progress 













1 





1 


- Setup 





X 





1 


- 


- 


- 


- 


Call information Phase Messages: 













1 


1 


1 


- Modify 










1 


1 


1 


1 


- Modify Complete 
















1 


1 


- Modify Reject 






















- User Information 










1 











- Hold 










1 








1 


- Hold Acknowledge 










1 





1 





- Hold Reject 










1 


1 








- Retrieve 










1 


1 





1 


- Retrieve Acknowledge 










1 


1 


1 





- Retrieve Reject 





X 


1 





- 


- 


- 


- 


Call Clearing Messages: 













1 





1 


- Disconnect 










1 


1 





1 


- Release 










1 





1 





- Release Complete 





X 


1 


1 


- 


- 


- 


- 


Miscellaneous Messages: 










1 








1 


- Congestion Control 










1 


1 


1 





- Notify 










1 


1 





1 


- Status 













1 








- Status Enquiry 













1 





1 


- Start DTMF 



















1 


- Stop DTMF 
















1 





- Stop DTMF Acknowledge 













1 


1 





- Start DTMF Acknowledge 













1 


1 


1 


- Start DTMF Reject 










1 





1 





- Facility 



NOTE: When used, the message type is defined in the following octet(s), according to the national specification. 
Bit 8 is reserved for possible future use as an extension bit, see GMR-2 04.007 [16]. 

Bit 7 is reserved for the send sequence number in messages sent from the MES. In messages sent from the Network, bit 
7 is coded with a "0". See GMR-2 04.007 [16]. This bit may be ignored for single hop mobile-to-mobile signalling. 
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1 1 .5 Other Information Elements 

The different formats (V, LV, T, TV, TLV) and the four categories of information elements (type 1, 2, 3, and 4) are 
defined in GMR-2 04.007 [16]. 

The first octet of an information element in the non-imperative part contains the lEl of the information element. If this 
octet does not correspond to an lEl known in the message (see GMR-2 04.007 [16]), the receiver shall assume that the 
information element is: 

a) Of type 1 or 2, i.e., that it is an information element of one octet length, if bit 8 of the first octet of the IE has the 
value 1; 

b) Of type 4, i.e., that the next octet is the length indicator indicating the length of the remaining information 
elements, if bit 8 of the first octet of the IE has the value 0. If in this case, bits 5, 6, and 7 of the first octet of the 
IE also have the value 0, the IE is encoded as "comprehension required." 

NOTE: The handling of messages containing unknown lEs encoded as "comprehension required" is specified in 
clause 9. 

This rule allows the receiver to jump over unknown information elements and to analyze any following information 
elements. 

The information element types which are common for at least two of the three protocols, Radio Resources management. 
Mobility Management and Call Control, are Usted in clause 11.5.1. 

The information element types for the protocols Radio Resources management. Mobility Management and Call Control 
are hsted in clauses 1 1 .5 .2, 1 1 .5 .3 and 1 1 .5 .4 respectively. Default information element identifiers are defined in tables 
11.5.1-1, 11.5.2-1, 11.5.3-1, and 11.5.4-1. 

NOTE: Different information elements may have the same default information element identifier if they belong to 
different protocols. 

The descriptions of the information element types in clauses 11.5.1, 11.5.2, 11.5.3, and 11.5.4 are organized in 
alphabetical order of the IE types. Each IE type is described in one clause. 

The clause may have an introduction: 

- possibly explaining the purpose of the IE; 

- possibly describing whether the IE belongs to type 1, 2, 3, or 4; 

- possibly indicating the length that the information element has if it is used in format TV (type 1 and 3) or TLV 
(type 4). 

A figure in the clause defines the structure of the IE indicating: 

- possibly the position and length of the lEl. (However it depends on the message in which the IE occurs whether 
the IE contains an lEl.); 

- the fields the IE value part is composed of; 

- possibly the position and length of the length indicator. (However it depends on the IE type whether the IE 
contains a length indicator or not.); 

- possibly octet numbers of the octets that compose the IE (see clause a) below). 

Finally, the clause contains tables defining the structure and value range of the fields that compose the IE value part. 
The order of appearance for information elements in a message is defined in clause 10. 

The order of the information elements within the imperative part of messages has been chosen so that information 
elements with 1/2 octet of content (type 1) go together in succession. The first type 1 information element occupies bits 
1 to 4 of octet N, the second bits 5 to 8 of octet N, the third bits 1 to 4 of octet N + 1 etc. If the number of type 1 
information elements is odd, then bits 5 to 8 of the last octet occupied by these information elements contains a spare 
half octet IE in format V. 
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Where the description of information elements in the present document contains bits defined to be "spare bits", these 
bits shall set to the indicated value (0 or 1) by the sending side, and their value shall be ignored by the receiving side. 
With few exceptions, spare bits are indicated as being set to "0" in the present document. 

The following rules apply for the coding of variable length information elements: 

a) The octet number of an octet (which is defined in the figure of a clause) consists of a positive integer, possibly of 
an additional letter, and possibly of an additional asterisk, see item f.). The positive integer identifies one octet or 
a group of octets; 

b) Each octet group is a self contained entity. The internal structure of an octet group may be defined in alternative 

ways; 

c) An octet group is formed by using some extension mechanism. The preferred extension mechanism is to extend 
an octet (N) through the next octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an extension bit. 

- The bit value "0" indicates that the octet group continues through to the next octet. The bit value "1" indicates 
that this octet is the last octet of the group. If one octet (Nb) is present, the preceding octets (N and Na) shall 
also be present. 

In the format descriptions appearing in clauses 1 1.5.1 through 1 1.5.4, bit 8 is marked "0/1 ext" if another 
octet follows. Bit 8 is marked " 1 ext" if this is the last octet in the extension domain. 

- Additional octets may be defined in later versions of the protocols ("1 ext" changed to "0/1 ext") and 
equipments shall be prepared to receive such additional octets. The contents of these octets shall be ignored. 
However the length indicated in clauses 10 and 1 1 only takes into account this version of the protocols; 

d) In addition to the extension mechanism defined above, an octet (N) may be extended through the next octet(s) (N 
+ 1, N + 2 etc.) by indications in bits 7-1 (of octet N). 

e) The mechanisms in c.) and d.) may be combined; 

f) Optional octets are marked wdth asterisks (*) 

11.5.1 Common Information Elements. 

For the common information elements types listed below, the default coding of information element identifier bits is 
summarized in table 11.5.1.1. 



Table 11.5.1.1: Information Element Identifier coding for common Information Elements 



















Reference 


8 7 


6 


5 


4 


3 


2 


1 




clause 


1 














Type 1 Info Elements 




1 1 


1 


1 










Note 



















Type 3 & 4 Info Elements 










1 











1 


Note 










1 








1 


1 


Location Area Indentification 


11.5.1.3 








1 





1 


1 


1 


Mobile Identity 


11.5.1.4 








1 


1 











Note 










1 


1 


1 


1 


1 


Note 







1 














1 


User Terminal Classmark 3 


11.5.1.7 
















Spare Half Octet 


11.5.1.8 


All other values are reserved 











11.5.1.1 Cell identity 

This clause does not apply to the GMR-2 system. 
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1 1 .5.1 .2 Ciphering Key Sequence Number 

The purpose of the Ciphering Key Sequence Number information element is to make it possible for the network to 
identify the ciphering key Kc which is stored in the MES without invoking the authentication procedure. The ciphering 
key sequence number is allocated by the Network and sent with the AUTHENTICATION REQUEST message to the 
MES where it is stored together with the calculated ciphering key Kc. 

The Ciphering Key Sequence Number information element is coded as shown in figure 11.5.1.1 and table 11.5.1.2. 
The Ciphering Key Sequence number is a type 1 information element. 



8 


7 6 5 


4 


3 2 1 






Ciphering Key Sequence 





Key Sequence 


octet 1 




Number lEI 


spare 







Figure 11.5.1.1: Ciphering Key Sequence Number Information Element Format 
Table 11.5.1.2: Ciphering Key Sequence Number Information Element Coding Standard 



Key Sequence (octet 1) 
Bits 



3 2 1 


through 

1 1 No key is available (MES to Network); 

1 1 1 Reserved (Network to MES) 



Possible values for the ciphering key sequence number 



1 1 .5.1 .3 Location Area Identification 

The purpose of the Location Area Identification information element is to provide an unambiguous identification of 

location areas within the area covered by the system. 

The Location Area Identification information element is coded as shown if figure 11.5.1.2 and table 11.5.1.3. 
The Location Area Identification is a type 3 information element with 6 octets length. 



8 7 6 5 4 3 2 1 



1 Location Area Identification lEI 


octet 1 


SSC/MCC digit 2 


SSC/MCC digit 1 


octet 2 


1 


1 1 1 1 


1 1 


SSC/MCC digit 3 


octet 3 


SSC/MCC digit 2 


SSC/MCC digit 1 


octet 4 






Location Area Code 


octet 5 






11.5.2.48 








Location Area Code 


octet 6 






1 1 .5.2.48 





Figure 11.5.1.1: Location Area Identification Information Element Format 
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Table 11.5.1.3: Location Area Identification Information Element Coding Standard 



When used in System Information Messages the following applies: 

SSC (Octets 2 and 3) 

The SSC will be used to indicate the Satellite System country. This allows the terminal to know its 
Home Satellite System or a Visited Satellite System. It shall be coded the same as the MCC field 
described below. 

SNC (Octet 4) 

The SNC allows the terminal to know which satellite in a multi-satellite system is providing the 
spotbeam and allows regional roaming concepts between satellites having overlapping but dissimilar 
geographical coverage as well as satellites having totally overlapping coverage. It shall be coded the 
same as the MNC field described below. 

When used in Mobility management messages, the following applies: 
MCC, Mobile country code (octet 2 and 3) 

The MCC field is coded as in ITU-T Recommendation E.212 [36] , Annex A. 

If the LAI is deleted, the MCC and MNC shall take the value from the deleted LAI. 

In abnormal cases, the MCC stored in the User Terminal can contain elements not in the set (0, 1 ... 
9). In such cases the User Terminal should transmit the stored values using full hexadecimal 
encoding. When receiving such an MCC, the network shall treat the LAI as deleted. 

MNC, Mobile network code (octet 4) 

The coding of this field is the responsibility of each administration but BCD coding shall be used. If an 
administration decides to include only one digit in the MNC then bits 5 to 8 of octet 4 are coded as 

"1111". 

NOTE: GMR-2 03.003 [7] defines that a 2 digit MNC shall be used, however the possibility to use a 
one digit MNC in LAI is provided on the radio interface. 

In abnormal cases, the MNC stored in the MES can have digit 1 not in the set (0, 1 .. 9) and/or digit 2 
not in the set (0, 1 ,...9, F) hex. In such cases the MES should transmit the stored values using full 
hexadecimal encoding. When receiving such an MNC, the network shall treat the LAI as deleted. 

Ordering: Digit 1 shall represent the leftmost digit of the field when the LAI is ordered from left to right, 
as shown in GMR-2 03.003 [7] 



11.5.1.4 Mobile Identity 

The purpose of the Mobile Identity information element is to provide either the international mobile subscriber identity, 
IMSI, or the international mobile equipment identity, IMEI together with the software version number, IMEISV. 

The IMSI shall not exceed 15 digits and the IMEI is composed of 15 digits, the IMEISV is 16 digits (see 
GMR-2 03.003 [7]). 

For all transactions except emergency call establishment, the identification procedure, and the ciphering mode setting 
procedure, the MES and the network shall select the IMSI as the mobile identity type. 

For emergency call establishment the MES shall have a SIM present and select the mobile identity type as IMSI. 
In the identification procedure the MES shall select the mobile identity type which was requested by the network. 
In the ciphering mode setting procedure the mobile shall select the IMEISV. 

The Mobile Identity information element is coded as shown in figure 11.5.1.3 and table 11.5.3.4. The value of N has a 
minimum length of 4 octets and a maximum length of 1 1 octets. 

The Mobile Identity is a type 4 information element. When it is used in a message, it has a minimum length of 3 octets 
and a maximum length of 10 octets. Further restriction on the length may be applied, e.g., number plans. 
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8 


7 6 5 


4 


3 2 1 




Mobile Identity lEI 




Length of mobile 


identity contents 


Identity digit 1 


odd/ 
even 
Idlcatlon 


Type of identity 


Identity digit 3 


Identity digit 2 



octet 1 
octet 2 
octet 3 



octet 4 



Identity digit p + 1 



Identity digit p 



octet 6 



Figure 11.5.1.3: Mobile Identity Information Element Format 
Table 11.5.1.4: Mobile Identity Information Element Coding Standard 



Type of identity (octet 3) 



Bits 








3 


2 


1 










1 


IMSI 





1 





IMEI 





1 


1 


IMEISV 


1 








Reserved 











No Identity (note) 



Odd/event indication (octet 3) 

Bit 

4 

even number of identity digits 

1 odd number of identity digits 

Identity digits (octet 3 etc) 

For the IMSI, IMEI and IMEISV this field is coded using BCD coding. If the number of 
identity digits is even then bits 5 to 8 of the last octet shall be filled with an end mark 
coded as "1111". 

Ordering: Identity digit 1 shall represent the leftmost digit of the field when the IMSI, IMEI, 
or IMEISV is ordered from left to right as shown in GMR-2 03.003 [7]. 

NOTE: This can be used in the case when a fill paging message without any valid 
identity has to be sent on the paging subchannel. 



11.5.1.5 MES Classmark 1 

The purpose of the MES Classmark 1 information element is to provide the network with information concerning 
aspects of high priority of the MES equipment. This affects the manner in which the network handles the operation of 
the MES. 

The MES Classmark 1 information element is coded as shown in figure 11.5.1.4 and table 11.5.1.5. 
The MES Classmark 1 is a type 3 information element with 2 octets length. 



8 


7 6 


5 


4 


3 2 1 




MES 


Classmark 1 lEI 




spare 


Revision Level 




spare 


EA/1 


RF power capability 



Figure 11.5.1.4: MES Classmark 1 Information Element Format 
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Table 11.5.1.5: MES Classmark 1 Information Element Coding Standard 



Revision Level (octet 2) 

Bits 

7 6 

Reserved 

I 1 I I Used by GMR-2 MESs 

All other values are reserved for future use 

EA/1 algorithm supported (octet 2, bit 4) 

encryption algorithm EA/1 available 

1 encryption algorithm EA/1 not available 

RF power capability (octet 2) 



Bits 








3 


2 


1 













class 1 (reserved) 








1 


class 2 





1 





class 3 





1 


1 


class 4 


1 








class 5 (reserved) 



All other values are reserved 



11.5.1.6 



MES Classmark 2 



The purpose of the MES Classmark 2 information element is to provide the network with information concerning 
aspects of both high and low priority of the MES equipment. This affects the manner in which the network handles the 

operation of the MES. 

The MES Classmark 2 information element is coded as shown in figure 11.5.1.5 and table 11.5.1.6. 
The MES Classmark 2 is a type 4 information element with 5 octets length. 

8 7 6 5 4 3 2 1 



User Terminal Classmark 2 lEI 


Length Of User Terminal Classmark 2 Contents 




spare 


Revision 
Level spare 


EA/1 


RF Power 
Capability 
















spare 




spare 


SS Screen 
Indicator 


SM 
capa- 
bility 




spare 




spare 


CMS 


MES Vocoder Capability 


° EA/3 
spare 


EA/2 



octet 1 
octet 2 
octet 3 



octet 4 



octet 5 



Figure: 11.5.1.5: MES Classmark 2 Information Element Format 

NOTE: Owing to backward compatibility problems, octet 4, bit 8 should not be used unless it is also checked that 
octet 3, bits 8, 7 and 6 are not "0 0". 
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Table 11.5.1.6: MES Classmark 2 Information Element Coding Standard 



Revision Level (octet 3) 
7 6 

Reserved 

1 Used by GMR-2 MESs 

All other values are reserved for future use 

EA/1 network equivalent algoritlim supported (octet 3, bit 4) 

encryption algoritlim EA/1 available 

1 encryption algorithm EA/1 not available 

EA/2 network equivalent algorithm supported (octet 5, bit 1 ) 

encryption algorithm EA/2 available 

1 encryption algorithm EA/2 not available 

E/V3 network equivalent algorithm supported (octet 5, bit 2) 

Encryption algorithm EA/3 available 

1 Encryption algorithm EA/3 not available 

RF power capability (octet 3) 



3 


2 


1 













class 1 (reserved) 








1 


class 2 





1 





class 3 





1 


1 


class 4 


1 








class 5 (reserved) 



All other values are reserved 



Classmark 3 (CU3) (octet 5, bit 8) 

No additional MES capability information available 

1 Additional MES capabilities are described in the Classmark 3 information 
element 

88 Screening indicator (octet 4) 
6 5 Bits 

Defined in GSM 04.80 [19] 

1 Defined in GSM 04.80 [19] 

1 Defined in GSM 04.80 [19] 
1 1 Defined in GSM 04.80 [19] 

SM capability (short message capability) (octet 4, bit 4) 

SM capability not present 

1 SM capability present 

MES Vocoder Capability (octet 5, bits 7 to 4) 
Bit? 

Quarter Rate Basic Speech Capability not present 

1 Quarter Rate Basic Speech Capability present 
Bite 

Eighth Rate Low Rate Speech Capability not present 

1 Eighth Rate Low Rate Speech Capability present 
Bits 

Reserved 
Bit 4 

Reserved 



NOTE: Additional MES capability information might be obtained by invoking the classmark interrogation 
procedure 

11.5.1.7 MES Classmark 3 

The purpose of the MES Classmark 3 information element is to provide the network with information concerning 
aspects of the MES. The contents might affect the manner in which the network handles the operation of the MES 
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The MES Classmark 3 information element is coded as shown in figure 11.5.1.6 and table 11.5.1.7. 
The MES Classmark 3 is a type 4 information element with a maximum of 14 octets length. 



8 


7 


6 5 


4 


3 


2 


1 




1 MES Classmark 3 lEI 


octet 1 


Length of MES Classmark 3 Contents 


octet 2 










spare 


EA/7 


EA/6 


EA/5 


EA/4 


octet 3 























octet 4- 






Spare 








14 



Figure 11.5.1.6: MES Classmark 3 Information Element Format 

Octets 4 to 14 are for future applications. The bits inside these octets are spare and these octets may be omitted. 
However, if octet n is present, then octet m shall also be present, where m <n. 

Table 11.5.1.7: MES Classmark 3 Information Element Coding Standard 



EA/4 algorithm supported (octet 3, bit 1 ) 

encryption algorithm EA/4 not available 

1 encryption algorithm EA/4 available 

EA/5 network equivalent algorithm supported (octet 3, bit 2) 

encryption algorithm E/V5 not available 

1 encryption algorithm E/V5 available 

EA/6 network equivalent algorithm supported (octet 3, bit 3) 

encryption algorithm EA/6 not available 

1 encryption algorithm EA/6 available 

EA/7 network equivalent algorithm supported (octet 3, bit 4) 

encryption algorithm EA/7 not available 

encryption algorithm EA/7 available 



11.5.1.8 Spare half octet 

This element is used in the description of messages in clause 10 when an odd number of half octet type 1 information 
elements are used. This element is filled with spare bits set to zero and is placed in bits 5 to 8 of the octet unless 
otherwise specified. 
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1 1 .5.2 Radio Resource Management Information Elements 

For the Radio Resource management information elements listed below, the default coding of the information element 
identifier bits is summarized in table 11.5.2.1. 



Table 11.5.2.1: Information Element Identifier Coding 
for Radio Resource Management Information Elements 



Reference 
clause 



7 


6 


5 4 3 2 1 


Type 1 info elements 










1 . . . . 


Cipher IVIode Setting 


11.5.2.9 





1 


- - - - 


Cipher Response 


11.5.2.10 





1 


1 . . . . 


Reserved 




1 





- - - - 


Reserved 




1 


1 


- - - - 


Channel Needed 


11.5.2.8 





















1 




















1 





1 





















1 


















1 





















1 


1 















1 















































1 

















1 




















1 


1 














1 


























1 

















1 




















1 


1 














1 




















1 





1 














1 


1 

















1 


1 


1 







































1 
















1 



















1 


1 













1 



















1 





1 













1 


1 
















1 


1 


1 



Type 3 & 4 Info Elements 

Reserved 

Reserved 

Reserved 

Reserved 

Channel Mode 

Channel Description 

Reserved 

Reserved 
Reserved 
Reserved 
Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Timing Advance 

Reserved 

Reserved 



11.5.2.6 
11.5.2.5 



1 1 .5.2.40 



11.5.2.1 Void 
11.5.2.1a BA range 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.1b Cell channel description 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.2 Cell description 

This clause does not apply to the GMR-2 system. 
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1 1 .5.2.3 Spotbeam options 

The purpose of the Spotbeam Options information element is to provide a variety of information about a spotbeam. 
The Spotbeam Options information element is coded as shown in figure 11.5.2.2 and table 11.5.2.2. 
The Spotbeam Options is a type 3 information element with 2 octets length. 



8 7 6 5 4 3 2 1 

I Spotbeam Description I El 

SB-BCCHext-Res I DTX I RADIO-LINK-TIIVIEOUT 



Figure 11.5.2.2: Spotbeam Options Information Element Format 
Table 11.5.2.2: Spotbeam Options Information Element Coding Standard 



SB-BCCHext-Res (Octet 2, bits 8 and 7) 
8 7 

S-BCCHext not in use 

1 S-BCCHext in use, Sys Info Message 7 only (option) 

1 S-BCCHext in use, Sys Info Message 8 only 

1 1 S-BCCHext in use, Sys Info Message 7 and 8 (option) 

DTX, DTX Indicator (octet 2, bits 6 and 5) Note 2 
6 5 

The MESs may use return discontinuous transmission 

1 The MESs shall use return discontinuous transmission 

1 The MESs shall not use return discontinuous transmission 

RADIO-LINK-TIMEOUT (octet 2, bits 4 to 1) Note 1 



4 


3 


2 


1 


S-SACCH value 














1 











1 


2 








1 





3 


1 


1 


1 





15 


1 


1 


1 


1 


16 



NOTE 1 : The precise meaning of the RADIO-LINK-TIMEOUT parameter can be found 

in GMR-2 05.008 [26]. 
NOTE 2: The DTX indicator field is not related to the use of forward discontinuous 

transmission. 



octet 1 
octet 2 



1 1 .5.2.4 Spotbeam selection parameters 

The purpose of the Spotbeam Selection Parameters information element is to provide a variety of information about a 

spotbeam. 

The Spotbeam Selection Parameters information element is coded as shown in figure 11.5.2.3 and table 11.5.2.3. 
The Spotbeam Selection Parameters information element is a type 3 information element with 3 octets length. 



8 7 6 


5 4 3 2 


1 




1 Spotbeam Selection Parameters lEI 


octet 1 


CELL-RESELECT 
HYSTERESIS 


MS-TXPWR-MAX-CCH 


octet 2 


spare | 


RXLEV-ACCESS-MIN 




octet 3 



Figure 11.5.2.3: Spotbeam Selection Parameters Information Element Format 
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Table 11.5.2.3: Spotbeam Selection Parameters Information Element Coding Standard 



CELL-RESELECT-HYSTERESIS (octet 2) 

The usage of this information is defined in GMR-2 05.008 [26] 

Bits 



8 


7 


6 






















dB 


RXLEV 


hysteresis for LA re-selection 








1 


2 


dB 


RXLEV 


hysteresis for LA re-selection 





1 





4 


dB 


RXLEV 


hysteresis for LA re-selection 





1 


1 


6 


dB 


RXLEV 


hysteresis for LA re-selection 


1 








8 


dB 


RXLEV 


hysteresis for LA re-selection 


1 





1 


10 


dB 


RXLEV 


hysteresis for LA re-selection 


1 


1 





12 


dB 


RXLEV 


hysteresis for LA re-selection 


1 


1 


1 


14 


dB 


RXLEV 


hysteresis for l_A re-selection 



MS-TXPWR-MAX-CCH (octet 2) 

The MS-TXPWR-MAX-CCH field is coded as the binary representation of the "power 
control level" in GMR-2 05.008 [26] corresponding to the maximum TX power level a 
MES may use when accessing on a Control Channel CGH. This value shall be used 
by the MES according to GMR-2 05.008 [26]. 

Range: 0to31. 

RXLEV-ACCESS-MIN (octet 3) 

The RXLEV-ACCESS-MIN field is coded as the binary representation of the minimum 
received signal level at the MES for which it is permitted to access the system. 

Range: to 63. (See GMR-2 05.008 [26]). 



1 1 .5.2.5 Channel description 

The purpose of the Channel Description information element is to provide a description of an allocable channel together 
with its S-SACCH. 

The Channel Description information element is coded as shown in figure 1 1.5.2.4 and table 1 1.5.2.4. 
The Channel Description is a type 3 information element with 5 octets length. 



8 7 6 5 4 3 2 1 



1 Channel Description lEI 


octet 1 


LARFCN 


octet 2 


FSMI / Channel Type 


FwdTN 


octet 3 


RSMI / Channel Type 


Rtn TN 


octet 4 


spare 


1 M-M 


TSC 


octet 5 



Figure 11.5.2.4: Channel Description Information Element Format 
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Table 11.5.2.4: Channel Description Information Element Coding Standard 



Channel Type (octet 3/forward, octet 4/return) 



Bits 



8 


7 


6 


5 


4 
















1 


S-TCH/F + ACCH/Fs 











1 


T 


S-TCH/H + ACCH/Hs 








1 


T 


T 


S-TCH/Q + ACCH/Qs 





1 


T 


T 


T 


S-TCH/E + ACCH/Es 


1 


1 


T 


T 


T 


S-SDCCH/E + ACCH/E 


1 





1 


T 


T 


S-SDCCH/Q + ACCH/Q (Reserved) 


1 











T 


S-SDCCH/HR + ACCH/HR (Reserved) 



The T bits indicate the Forward Submultiplex Index, and Return Submultiplex Index, in binary. All 

other values are reserved. 

Fwd TN, Timeslot number (octet 3) 

The TN field is coded as the binary representation of the timeslot number as defined in 
GMR-2 05.010 [27]. 
Range: to 7. 

Rtn TN, Timeslot number (octet 4) 

The TN field is coded as the binary representation of the timeslot number as defined in 
GMR-2 05.010 [27]. 
Range: to 7. 

TSC, Training Sequence Code (octet 5) 

The TSC field is coded as the binary representation of the Training Sequence code as defined in 
GMR-2 05.003 [24] 
Range: to 7. 

LARFCN, (octet 2) 

The ARFCN is coded as the binary representation of the absolute L-B and RF channel number 
Range: to 1 69 

M-M, (bit 4 in octet 5) 

Set to one for mobile to mobile single hop calls; otherwise set to zero. 



11.5.2.6 Channel mode 

The Channel Mode information element gives information of the mode of coding/decoding and transcoding. 
The Channel Mode information element is coded as shown in figure 1 1.5.2.5 and table 1 1.5.2.5. 
The Channel Mode is a type 3 information element with 2 octets length. 

8 7 6 5 4 3 2 1 

I Channel Mode lEI 

Mode 



Figure 11.5.2.5: Channel Mode Information Element Format 
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Table 11.5.2.5: Channel Mode Information Element Coding Standard 



Mode (octet 2) 
Bits 



8 


7 


6 


5 


4 


3 


2 1 

























Signalling only 











1 





1 


1 


speech half rate (robust mode) 

















1 


1 


speech half rate (enhanced mode) 














1 





1 


speech quarter rate 














1 


1 


1 


speech eighth rate (reserved) 




















1 1 


data, full rate, 12 kbits/s radio interface rate (reserved) 











1 





1 


1 1 


data, half rate, 6 kbits/s radio interface rate (reserved) 








1 





1 





1 1 


data, quarter rate, 3 kbits/s radio interface rate 








1 








1 


1 1 


data, half rate, 3 kbits/s radio interface rate (reserved) 



Other values are reserved for future use 



11.5.2.7 Channel Mode 2 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.8 Channel needed 

The purpose of the Channel Needed information element is to indicate to a MES class, as defined in clause 4.3.21, 
which type of channel is needed for the transaction linked to the paging procedure. 

The Channel Needed information element is coded as shown in figure 11.5.2.6 and table 11.5.2.6. 

The Channel Needed is a type 1 information element. 

8 7 6 5 4 3 2 1 

I Channel Needed lEI | spare | CHANNEL 1 octet 1 

Figure 11.5.2.6: Channel Needed Information Element Format 

Table 11.5.2.6: Channel Needed Information Element Coding Standard 

CHANNEL (octet 1) 



Bits 








3 


2 


1 













Any channel 








1 


S-SDCCH 





1 





S-TCH/F (full rate) (reserved) 





1 


1 


S-TCH/H (half rate) (reserved) 


1 








S-TCH/Q (quarter rate) (reserved) 


1 





1 


S-TCH/E (eighth rate) (reserved) 


1 


1 





S-SDCCH/Q (reserved) 


1 


1 


1 


S-SDCCH/HR (reserved) 



1 1 .5.2.9 Cipher mode setting 

The purpose of the Cipher Mode Setting information element is to indicate whether stream ciphering shall be started or 
not and if it is to be started, which algorithm to use. 

The Cipher Mode Setting information element is coded as shown in figure 1 1.5.2.7 and table 1 1.5.2.7. 
The Cipher Mode Setting is a type 1 information element. 
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8 


7 6 5 


4 3 2 


1 


spare 


Ciph Mod Set lEI 


Algorithm Identifier 


SC 



Figure 11.5.2.7: Cipher iUlode Setting Information Element Format 
Table 11.5.2.7: Cipher Mode Setting Information Element Coding Standard 



Algorithm Identifier 
if SC = 1 then: 



bits 








4 


3 


2 













cipher with algorithm EA/1 








1 


cipher with algorithm EA/2 (reserved) 





1 





cipher with algorithm EA/3 (reserved) 





1 


1 


cipher with algorithm EA/4 (reserved) 


1 








cipher with algorithm EA/5 (reserved) 


1 





1 


cipher with algorithm EA/6 (reserved) 


1 


1 





cipher with algorithm EA/7 (reserved) 


1 


1 


1 


Reserved 



If SC = then bits 4,3 and 2 are spare 

SC (octet 1) 

Bit 

1 

No ciphering 
J Start ciphering 



11.5.2.10 Cipher response 

The Cipher Response information element is used by the network to indicate to the MES which information the MES 
has to include in the CIPHERING MODE COMPLETE message. 

The Cipher Response information element is coded as shown in figure 11.5.2.8 and table 11.5.2.8. 
The Cipher Response is a type 1 information element. 

8 7 6 5 4 3 2 1 

I spare | Cipher Response lEI | spare | CR ~| octet 1 



Figure 11.5.2.8: Cipher Response Information Element Format 



Table 11.5.2.8: Cipher Response Information Element Coding Standard 



Cipher response (octet 1) 




Bit 
1 







IMEISV shall not be included 


1 


IMEISV shall be included 



1 1 .5.2.1 1 Control channel description 

The purpose of the Control Channel Description information element is to provide a variety of information about a 
spotbeam. 

The Control Channel Description information element is coded as shown in figure 11.5.2.9 and table 11.5.2.9. 
The Control Channel Description is a type 3 information element with 4 octets length. 
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8 


7 


6 


5 


4 


3 2 1 




spare 


Control Channel Description lEI 


octet 1 

















CCCH-CONF 


octet 2 


spare 


spare 


spare 


spare 


spare 






BS-AG-BLKS-RES 


BS-PA-MFRMS 


octet 3 








T3212 




octet 4 








time-out value 







Figure 11.5.2.9: Control Channel Description Information Element Format 



Table 11.5.2.9: Control Channel Description Information Element Coding Standard 



CCCH-CONF (octet 2) 
Bits 

3 2 1 

One basic forward TN (TN_0) used for S-HMSCH, S-HBCCH, S-SCH, S-BCCH, 

S-AGCH and S-PCH and two return TNs (one return sub-channel) used for S- 
RACH. The actual return sub-channels used for the S-RACH are set by the 
SB_RACH_X parameters discussed in clause 11. 5.2.45. 7 

1 Reserved 

1 Two basic forward TNs, the first TN (TN_0) used for S-HMSCH, S-HBCCH, S- 

SCH, S-BCCH, S-AGCH and S-PCH, the second TN is a CCCH extension as 
specified in GMR-2 05.002 [23] and is used for S-AGCH/S-PCH only, and four 
return TNs (two return sub-channels) used for S-RACH. The actual return sub- 
channels used for the S-RACH are set by the SB_RACH_X parameters 
discussed in clause 1 1 .5.2.45. 

1 1 Three basic forward TNs, the first TN (TN_0) used for S-HMSCH, S-HBCCH, S- 

SCH, S-BCCH, S-AGCH and S-PCH, the second and third TNs are CCCH 
extensions as specified in GMR-2 05.002 [23], clause 8.5.1 (see also table 5.3.4) 
and are used for S-AGCH/S-PCH only, and six return TNs (three return sub- 
channels) used for S-RACH. The actual return sub-channels used for the S- 
RACH are set by the SB RACH X parameters discussed in clause 1 1 .5.2.45. 

1 Four basic forward TNs, the first TN (TN_0) used for S-HMSCH, S-HBCCH, S- 

SCH, S-BCCH, S-AGCH and S-PCH, the second, third and fourth TNs are CCCH 
extensions as specified in GMR-2 05.002 [23], clause 8.5.1 (see also table 5.3.4) 
and are used for S-AGCH/S-PCH only, and eight return TNs (four return sub- 
channels) used for S-RACH. The actual return sub-channels used for the S- 
RACH are set by the SB_RACH_X parameters discussed in clause 1 1 .5.2.45. 
all other values are reserved 

BS-AG-BLKS-RES (octet 3) 

The BS-AG-BLKS-RES field is coded as the binary representation of the number of blocks 
reserved for access grant with the most significant bit in bit 8. 

Range to 21 for all values of CCCH-CONF. 
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Table 11.5.2.9 (cont): Control Channel Description Information Element Coding Standard 



BS-PA-MFRMS (octet3) 



Bits 








3 


2 


1 













1 1 02 multiframe period for transmission of PAGING REQUEST messages to tlie 

same paging subgroup 








1 


2 102 multiframe periods for transmission of PAGING REQUEST messages to 
the same paging subgroup 





1 





3 1 02 multiframe periods for transmission of PAGING REQUEST messages to 
the same paging subgroup 





1 


1 


4 1 02 multiframe periods for transmission of PAGING REQUEST messages to 

the same paging subgroup 


1 








5 1 02 multiframe periods for transmission of PAGING REQUEST messages to 
the same paging subgroup 



All other values are reserved 

T321 2 time-out value (octet 4) 

The T321 2 time-out value field is coded as the binary representation of the time-out value for 
periodic updating in decihours. 

Range: 1 to 255 

The value is used for infinite time-out value 

i.e. periodic updating shall not be used within the spotbeam. 



11.5.2.12 Frequency Channel Sequence 

This clause does not apply to the GMR-2 system. 

11.5.2.13 Frequency List 

This clause does not apply to the GMR-2 system. 

11.5.2.14 Frequency Short List 

This clause does not apply to the GMR-2 system. 

11.5.2.15 Handover Reference 

This clause does not apply to the GMR-2 system. 

11.5.2.16 lA Rest Octets 

This clause does not apply to the GMR-2 system. 

11.5.2.17 I AR Rest Octets 

This clause does not apply to the GMR-2 system. 

11.5.2.18 I AX Rest Octets 

This clause does not apply to the GMR-2 system. 

11.5.2.19 L2 pseudo length 

The L2 Pseudo Length information element indicates the number of octets following it in the message which are to be 
interpreted in the scope of the phase 1 protocol. 

The L2 Pseudo Length information element is the first part of e.g., SYSTEM INFORMATION messages which are 
mentioned as exceptions in clause 11.1. It occupies the first octet of such messages. 
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The L2 Pseudo Length Information element is an element with 2 octets length. 



8 


7 


6 5 4 3 


2 


1 




spare | 




L2 Pseudo Length lEI 






octet 1 






L2 Pseudo Length value 





1 


octet 2 



Figure 11.5.2.10: L2 Pseudo Length Information Element Format 
Table 11.5.2.10: L2 Pseudo Length Information Element Coding Standard 



L2 pseudo length value (octet 2) 

The coding of the L2 pseudo length value field is the binary representation 
of the L2 pseudo length of the message in which the L2 pseudo length 

information element occurs. 

NOTE: bits 1 and 2 are not spare. 



1 1 .5.2.20 Measurement Results 

The purpose of the Measurement Results information element is to provide the results of the measurements made by the 
MES on the serving spotbeam. 

The Measurement Results information element is coded as shown in figure 11.5.2.11 and table 11.5.2.11. 
The Measurement Results is a type 3 information element with 4 octets length 



8 7 6 5 4 3 2 1 





Measurement Results lEI 


Octet 1 


DTX 


DTX 


RXLEV-FULL-SERVING-CELL 


Octet 2 


Detect 


Used 











MEAS 


RXLEV-SUB-SERVING-CELL 


Octet 3 


spare 


VALID 










RXQUAL-FULL 


RXQUAL-SUB 


Octet 4 




SERVING-CELL 


SERVING-CELL 





Figure 11.5.2.11: Measurement Results Information Element Format 
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Table 11.5.2.11: Measurement Results Information Element Coding Standard 



DTX-USER (octet 2) 

This bit indicates wlietlier or not tine MES used DTX during tine previous measurement period. 

Bit 
7 

DTX was not used 

1 DTX was used 

DTX- Detect (octet 2) 

This bit indicates whether or not the MES detected DTX in the measurement period. 

Bit 
8 

DTX was not detected 

1 DTX was detected 

RXLEV-FULL-SERVING-CELL and RXLEV-SUB-SERVING-CELL (octets 2 and 3) 

Received signal strength on serving beam, measured respectively on all slots and on a subset 
of slots (see GMR-2 05.008 [26]) 

The RXLEV-FULL-SERVING-CELL and RXLEV-SUB-SERVING- CELL 

fields are coded as the binary representation of a value N. N corresponds according to the 
mapping defined in GMR-2 05.008 [26] to the received signal strength on the serving 
spotbeam. 

Range: to 63 

MEAS- VALID (octet 3) 

This bit indicates if the measurement results for the dedicated channel are valid or not 

Bit 
7 

The measurement results are valid 

1 The measurement results are not valid 

RXQUAL-FULL-SERVING-GELL and RXQUAL-SUB-SERVING- CELL (octet 4) 

Received signal quality on serving beam, measured respectively on all slots and on a subset 

of the slots (see GMR-2 05.008 [26]) 
The RXQUAL-FULL-SERVING-CELL and RXQUAL-SUB-SERVING- 

GELL fields are coded as the binary representation of the received signal quality on the 

serving spotbeam. 

Range: to 7 (See GMR-2 05.008 [26]) 



1 1 .5.2.21 Mobile Allocation 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.21 a Mobile Time Difference 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.22 Neighbour spotbeams description 

The purpose of the Neighbour Spotbeams Description information element is to provide the absolute radio frequency 
channel numbers of the S-BCCH carriers to be monitored by the MESs in the beam. The S-BCCH carriers to be 
monitored include carriers of adjacent spotbeams as well as spotbeams from other spacecraft within the system which 
overlap depending upon the System Information Message that invokes the Information element. 

When used in the System Information Type 2 message, the IE contains six frequencies and uses 15 octets - from octet 
number 2 to octet number 16. 
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When used in the System Information Type 7 message, the IE contains seven frequencies and uses 18 octets - from 
octet number 2 to octet number 19. 



8 


7 6 


5 


4 


3 2 


1 








Neighbour Spotbeam 


Description lEI 




octet 1 


LARFCN 1 


octet 2 


CO (MSBs) 1 


octet 3 


CO 


FSG 


F01 




LARFCN 2 (MSBs) 




octet 4 


(LSBs) 1 


1 












LARFCN 2 (LSBs) 


CO 2 (MSBs) 


octet 5 




CO 2 (LSBs) 




1 FSG 2 1 


F0 2 


octet 6 



CO 
(LSBs) 5 


FSG 5 


F0 5 


LARFCN 6 (MSBs) 


octet 14 


LARFCN 6 (LSBs) 


CO 6 (MSBs) 


octet 1 5 




CO 6(LSBs) 






1 FSG 6 1 F0 6 


octet 1 6 


LARFCN 7 


octet 17 


CO 7 (MSBs) 


octet 18 


CO 7 
(LSBs) 


FSG 7 


F0 7 


bi value 


spare 


octet 19 



Figure 11.5.2.12: Neighbour Spotbeams Description Information Element Format 
Table 1.5.2.12: Neighbour Spotbeams Description Information Element Coding Standard 



The following parameters are repeated for each frequency used in the IE. 

LARFCN (various octets) 

See clause 1 1 .5.2.5. Binary 255 (xFF) shall indicate a spotbeam that does not exist or 
does not have a CCS frequency. 

CO (various octets) 
See clause 11.5.2.46 

FSG (various octets) 
See clause 1 1 .5.2.46 

FO (various octets) 
See clause 1 1 .5.2.46 

bi Value (octet 19, bits 4 and 3) 

A binary valued with MSB in bit 4. Its ranges from 1 to 2. Binary is reserved for the 
satellite providing the current spotbeam. Binary 3 is not allowed. 
This parameter is associated with IE clause 1 1 .5.2.44 in a unique correspondence when 
this IE is used in a System Information Type 7 message. The Channel Request message 
and The Immediate Assignment message use this value in lieu of IE clause 1 1 .5.2.44 
during MES visibility reporting reassignment to another satellite, respectively. 



1 1 .5.2.23 P1 rest octets 

The PI Rest Octets information element contains only spare bits only. Its purpose is to allow the upward compatible 
introduction of new information on the S-PCH in later phases. 

The PI Rest Octets information element is a type 5 information element with 1-18 octets length. 
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8 


7 


6 


5 


4 


3 


2 


1 








P1 


Rest Octets lEI 






spare 


spare 


1 spare 


spare 


1 spare 


spare 


1 spare 


1 spare 


spare 


spare 


1 spare 


spare 


1 spare 


spare 


1 spare 


1 spare 



octet 1 
octet 2 
octet 3 



spare 


spare 


1 spare 


spare 


1 spare 


spare 


1 spare 


1 spare 



octet n 



Figure 11.5.2.13: PI Rest Octets Information Element Format 

1 1 .5.2.24 P2 Rest Octets 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.25 P3 Rest Octets 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.26 Page mode 

The purpose of the Page Mode information element is to control the action of the MES belonging to the paging 
subgroup corresponding to the paging subchannel. 

The Page Mode information element is coded as shown in figure 11.5.2.14 and table 11.5.2.14. 
The Page Mode is a type 1 information element. 



8 


7 6 5 


4 


3 


2 


1 




Page Mode lEI 




spare 


PM 



octet 1 



Figure 11.5.2.14: Page Mode Information Element Format 
Table 11.5.2.14: Page lUlode Information Element Coding Standard 



PM (octet 1) 




Bits 






3 2 


1 










Normal paging 





1 


Extended paging 


1 





Paging reorganization 


1 


1 


Reserved 


1 1 


1 


SMS paging 


All other values reserved 



1 1 .5.2.27 Network Colour Code (NCC) permitted 

The purpose of the NCC Permitted information element is to provide a definition of the allowed satellite network color 
codes (NCC) on the BCCH carriers to be monitored in idle mode. 

The NCC Permitted information element is coded as shown in figure 11.5.2.15 and table 11.5.2.15. 
The NCC Permitted information element is a type 3 information element with two octets length. 
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2 1 



NCC Permitted I El 



NCC Permitted 



octet 1 
octet 2 



Figure 11.5.2.15: NCC Permitted Information Element Format 
Table 11.5.2.15: NCC Permitted Information Element Coding Standard 



NCC Permitted (octet 2) 

The NCC permitted field is coded as a bit map, i.e. bit N is coded with a "0" 
if the S-BCCH carrier with NCC = N-1 is not permitted for monitoring and 
with a "1 " if the S-BCCH carrier with NCC = N-1 is permitted for monitoring; 
N=1,2,...,8. 



1 1 .5.2.28 Power command 

The purpose of the Power Command information element is to provide the power level to be used by the User Terminal. 
The Power Command information element is coded as shown in figure 11.5.2.16 and table 11.5.2.16. 
The Power Command is a type 3 information element with 2 octets length. 



8 


7 


6 


5 4 3 


2 


1 


spare 


Power Command lEI 










POWER LEVEL 






spare 


spare 











octet 1 
octet 2 



Figure 11.5.2.16: NCC Permitted Information Element Format 
Table 11.5.2.16: NCC Permitted Information Element Coding Standard 



Power level (octet 2) 

The power level field is coded as the binary representation of the "power 
control level", see GMR-2 05.005 [25]. This value shall be used by the 
User Terminal according to GMR-2 05.008 [26]. 

Range: to 64. Actual range defined in GMR-2 05.005 [25]. 



1 1 .5.2.29 S-RACH control parameters 

The purpose of the S-RACH Control Parameters information element is to provide parameters used to control the S- 
RACH utiUzation. This information element is broadcast to MESs in SYSTEM INFORMATION TYPE 2, 3, 9, and 10 

messages. 

The S-RACH Control Parameters information element is coded as shown in figure 11.5.2.17 and table 11.5.2.17. 
The S-RACH Control Parameters is a type 3 information element with 4 octets length. 



8 


7 


6 


5 


4 


3 


2 


1 




spare 


S-RACH Control Parameters lEI 


octet 1 


Max retrans 




Tx-integer mod 




CELL 


RE 


octet 2 














BARR 


















ACCESS 






AC 


AC 


AC 


SDCCH 


LU 


EC 


AC 


AC 


octet 3 


C15 


C14 


C13 


C12 


C11 


C10 


C09 


COS 




AC 


AC 


AC 


AC 


AC 


AC 


AC 


AC 


octet 4 


CO? 


C06 


C05 


C04 


Co3 


C02 


C01 


COO 





Figure 11.5.2.17: S-RACH Control Parameters Information Element Format 
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Table 11.5.2.17: S-RACH Control Parameters Information Element Coding Standard 



Max retrans, Maximum number of retransmissions (octet 2, bits 8 and 7) 
8 7 

Maximum 1 retransmission 

1 Maximum 2 retransmissions 

1 Maximum 3 retransmissions 
1 1 Maximum 5 retransmissions 

Tx-integer mod (octet 2, bits 6 to 3), Number of S-RACH slots over which transmission is spread 
(randomized). The corresponding number of frames periods is determined by the S-RACH 
configuration parameter. 



6 


5 


4 


3 
















3 











1 


4 








1 





5 








1 


1 


6 





1 








7 





1 





1 


8 





1 


1 





9 





1 


1 


1 


10 


1 











11 


1 








1 


12 


1 





1 





14 


1 





1 


1 


16 


1 


1 








20 


1 


1 





1 


25 


1 


1 


1 





32 


1 


1 


1 


1 


50 



CELL_BAR_ACCESS, Spotbeam Barred for Access (octet 2, bit 2) 

The spotbeam is not barred, see GMR-2 03.022 [1 0] 

1 The spotbeam is barred, see GMR-2 03.022 [1 0] 

RE, Call re-establishment allowed (octet 2, bit 1 ) 

1 Call Re-establishment not allowed in the spotbeam 

EC Emergency Call allowed (octet 3, bit 3) 

Emergency call allowed in the spotbeam to all MESs. 

1 Emergency call not allowed in the spotbeam except for the MESs that belong to one of 
the classes 13 to 15. 

LU Location Updates allowed (octet 3, bit 4) 

Location Updates allowed in the spotbeam 

1 Location Updates not allowed in the spotbeam, except those belonging to classes 1 3 to 
15 

SDCCH for other procedures allowed (octet 3, bit 5) 

SDCCH for other procedures allowed in the spotbeam 

1 SDCCH for other procedures not allowed in the spotbeam, except for the MESs that 

belong to other classes between 13 and 15 

AC CN, Access Control Class N (octet 3(except bits 3, 4, 5)and octet 4) 

For a MES with AC C = N access is not barred if the AC CN bit is coded with a "0"; N = 0, 1 , . . 
9,13, . ., 15. Access classes 13 to 15 are reserved 



1 1 .5.2.30 Request reference 

The purpose of the Request Reference information element is to provide a method to uniquely identify User Terminal 
responses to paging messages. 

The Request Reference information element is coded as shown in figure 11.5.2.18 and table 11.5.2.18. 
The Request Reference is a type 3 information element with 7 octets length. 
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8 


7 6 5 


4 3 2 1 






Request Reference lEI 




Establishment Cause / Random Access 


Message (Half Octet B) 


nrtpt P 




(Half Octet A) 




Message (Half Octet C) 


Message (Half Octet D) 


octet 3 


Message (Half Octet E) 


Message (Half Octet F) 


octet 4 


spare 


Message (Half Octet G) 


octet 5 




TV 


1 Reference Message 


octet 6 




spare | 


T2 


octet 7 



Figure 11.5.2.18: Request Reference Information Element Format 
Table 11.5.2.18: Request Reference Information Element Coding Standard 



Channel Request Message (Octet 2 to 5) 

The Channel Request message, with a format as specified in clause 1 0.1 .8 that originated the 

response. 

T1' Reduced Superframe Count (octet 6 , bits 8 to 4) 

The TV field is coded as the binary representation of (FN div [51x26]) mod 32. 

T2 (octet?, bits 5 to 1) 

The T2 field is coded as the binary representation of FN mod 26. 

T1 ' and T2 represent the first Frame Number (FN) of the RACH slot in which the Channel 
Request message was received by the network. For example, if a RACH slot has 4 frames 
labeled FN+0, FN+1, FN+2, and FN+3, then the frame number would be FN+0. 

Reference Message (octet 6 , bits 3 to 1 ) 

The purpose of the Reference Message is to provide information and/or direction to the User 

Terminal associated with a request of the network. 

The first two bits of the Reference Message (octet 6 , bits 3 and 2) indicate a feedback code. 
The last bit of the Reference Message (octet 6 , bit 1) contain feedback message information. 
If the first two bits of the Reference Message are all O's then the Reference Message can be 
ignored. If the NCC is unable to route a MES origination because of an unknown international 
number, the message. Requested Number Unknown, shall be used. The NCC shall use the 
message. Request new channel on the bl, to redirect the user origination to another spacecraft. 



Octet 6 






Octet 6 


Bits 






Bit 


3 


2 




1 








Ignore Reference Message 








1 


Requested Number Unknown 





1 





Request new channel on the 


b 



where b is a binary zero if the call is redirected to the satellite having a bl value of one and is a 

binary one if the call is redirected to the satellite having a bl value of two. 

The bl values are sent in to the MES in System Information Type 7 messages in lEI 1 1.5.2.22. 

Each value is uniquely associated with a Satellite System Code, lEI 1 1 .5.2.44, which specifies a 

satellite. 



NOTE: The NCC capability to use the message, request new channel on the bl to redirect the user origination to 
another satellite is a future growth capability. 

11.5.2.31 RR cause 

The purpose of the RR Cause information element is to provide the reason for release or the reason for completion of an 

assignment or handover. 

The RR Cause information element is coded as shown in figure 11.5.2.19 and table 11.5.2.19. 
The RR Cause is a type 3 information element with 2 octets length. 
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8 


7 6 5 4 3 2 1 






RR Cause lEI 


octet 1 


RR cause value 


octet 2 




Figure 11.5.2.19: RR Cause Information Element Format 






Table 11.5.2.19: RR Cause Information Element Coding Standard 





RR cause value (octet 2) 



Bits 



8 


7 


6 


5 


4 


3 


2 


1 




























Normal event 























1 


Abnormal release, unspecified 




















1 





Abnormal release, channel unacceptable 




















1 


1 


Abnormal release, timer expired 

















1 








Abnormal release, no activity on the radio path 

















1 





1 


Preemptive release 

















1 


1 





Satellite Mobile to Mobile Link failure 

















1 


1 


1 


Local Transmit Disable by the network 














1 











Handover impossible, timing advance out of range 














1 








1 


Channel mode unacceptable 














1 





1 





Frequency not implemented 






















1 


Call already cleared 










1 


1 


1 


1 


1 


Semantically incorrect message 
























Invalid mandatory information 





















1 


Message type non-existant or not implemented 


















1 





Message typenot compatible with protocol state 















1 








Conditional IE error 















1 





1 


No spotbeam allocation available 












1 


1 


1 


1 


Protocol error unspecified 



All other cause values shall be treated as 0000 0000, "normal event" 



The listed RR cause values are defined in Annex F. 



1 1 .5.2.32 SI 1 Rest Octets 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.33 SI 2bis Rest Octets 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.34 Spotbeam Re-selection Parameters 

The Spotbeam Re-selection parameters information element includes parameters which are used by the MES for 
spotbeam reselection purposes. 

The meaning of the parameters in octet 2 and 3 are determined by the value of PI as indicated in figure 1 1.5.2.20 and 
described in table 11.5.2.20. 

The Spotbeam Re-selection parameters information element is a type 5 information element with 3 octets length. 



8 


7 6 


5 4 3 2 


1 






Spotbeam Re-selection Parameters 


octet 1 


PI 


CBQ 1 


CELL RESELECT OFFSET 




octet 2 


TEMPORARY_OFFSET 


PENALTY_TIME 


octet 3 



Figure 11.5.2.20: Spotbeam Re-selection Parameters Information Element Format 
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Table 11.5.2.20: Spotbeam Re-selection Parameters Information Element Coding Standard 



PI, CELL_RESELECT_PARAM_IND (octet 2) 
PI Value 

1 C2 Parameters present 
C2 Parameters not present 

PI is used by the MESto determine if the C2 parameters which are, CBQ, CELL 
RESELECT_OFFSET, TEMPORARY_OFFSET and PENALTY_TIME are being broadcast 
by the network in this message. The C2 parameters shall always be present i.e., PI = 1 . 

CBQ, CELL_BAR_QUALIFY (octet 2) 

CELL_BAR_QUALIFY is used by the network to control MES spotbeam selection and 
reselection. The use and coding of this parameter is defined in GMR-2 05.008 [26]. 

CELL_RESELECT_OFFSET (octet 2) 

CELL_RESELECT_OFFSET is coded as the binary representation of the 
"CELL_RESELECT_OFFSET" in GMR-2 05.008 [26]. It is a value used by the MES to apply 
a positive or negative offset to the value of C2 as defined in GMR-2 03.022 [10] and 
GMR-2 05.008 [26]. 

TEMPORARY_OFFSET (octet 3) 

The TEMPORARY_OFFSET field is coded as the binary representation of the 
"TEMPORARY_OFFSET" in GMR-2 05.008 [26]. It is used by the MES as part of its 
calculation of C2 for the spotbeam reselection process as described in GMR-2 05.008 [26]. 
It is used to apply a negative offset to C2 for the duration of PENALTY_TIME. 

PENALTY_TIME (octet 3) 

The PENALTY TIME is coded as the binary representation of the "PENALTY_TIME" in 
GMR-2 05.008 [26]. It defines the length of time for which TEMPORARY OFFSET is active. 
The usage of PENALTY_TIME is described in GMR-2 03.022 [10] and 
GMR-2 05.008 [26]. 



1 1 .5.2.35 SI 4 Rest Octets 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.36 SI 7 Rest Octets 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.37 SI 8 Rest Octets 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.38 Starting Time 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.39 Synchronization Indication 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.40 Fine timing advance 

The purpose of the Fine Timing Advance information element is to provide the fine timing advance value. 
The Fine Timing Advance information element is coded as shown in figure 11.5.2.22 and table 11.5.2.22. 
The Fine Timing Advance is a type 3 information element with 3 octets length. 
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spare 



Timing Advance lEI 



Octet 1 
octet 2 
octet 3 



Timing advance (liigli) 



Timing advance (low) 



Figure 11.5.2.22: Fine Timing Advance Information Element Format 
Table 11.5.2.22: Fine Timing Advance Information Element Coding Standard 



Fine Timing advance value (octet 2 and 3) 

The coding of the timing advance value field Is the binary representation of the 
timing advance In return quarter-bit periods; 1 return quarter-bit period = 48/13 
us. 



1 1 .5.2.41 Time Difference 

This clause does not apply to the GMR-2 system. 

11.5.2.42 TMSI 

This clause does not apply to the GMR-2 system. 

1 1 .5.2.43 Wait indication 

The purpose of the Wait Indication information element is to provide the time the MES shall wait before attempting 

another channel request. 

The Wait Indication information element is coded as shown in figure 1 1.5.2.23 and table 1 1.5.2.23. 
The Wait Indication is a type 3 information element with 2 octets length. 

8 7 6 5 4 3 2 1 



spare 



Walt Indication lEI 



T3122 Time-outvalue 



octet 1 
octet 2 



Figure 11.5.2.23: Wait Indication Information Element Format 
Table 11.5.2.23: Wait Indication Information Element Coding Standard 



T 3122 Time-out Value (octet 2) 

This field Is coded as the binary representation of the T 3122 time-out value In 
seconds 



1 1 .5.2.44 Satellite system code 

The Satellite System Code Information Element provides the Satellite System Country code (SSC) and Satellite 
Network Code (SNC) associated the information broadcast on the Type 7 System information message. 

The information is coded as shown in figure 11.5.2.24 and table 11.5.2.24. 

The Satellite System Code Information Element is a type 3 element with 4 octets. 
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8 7 6 5 4 3 2 1 


spare 


Satellite System Code lEI 


SSC2 


SSC 1 


1 1 1 1 1 1 1 


BSC 3 


SNC 2 


SNC 1 



octet 1 
octet 2 
octet 3 
octet 4 



Figure 11.5.2.24: Satellite System Code Information Element Format 
Table 11.5.2.24: Satellite System Code Information Element Coding Standard 



SSC (Octets 2 and 3) 

The SSC will be used to indicate the Satellite System country. This allows the 
terminal to know its Home Satellite System or a Visited Satellite System. 

SNC (Octet 4) 

The SNC allows the terminal to know which satellite in a multi-satellite system is 
providing the spotbeam. 



1 1 .5.2.45 CCS configuration parameters 

The CCS Configuration Parameters information element provides the Coarse Timing Advance and S-RACH 
configuration required to establish a connection to the network. The Coarse Timing Advance, along with the Forward 
Epoch Delay, 1 1 .5.2.46, are required to establish system time at the MES for transmissions in the MES - Network 

direction. 

The information is coded as shown in figure 1 1.5.2.25 and table 1 1.5.2.25. 

The CCS Configuration Parameters information element is a type 3 element with 5 octets. 



8 


7 


6 5 


4 3 


2 1 




1 CCS Configuration Parameters lEI 


octet 1 


CTA (high) 


octet 2 


CTA (middle) 


octet 3 


CTA 


S-RACH Configuration 


S-BCCH Power Reference 


octet 4 


(low) 












SB-RACH-0 


SB-RACH-1 


SB-RACH-2 


SB-RACH-3 


octet 5 



Figure 11.5.2.25: CCS Configuration Parameters Information Element Format 
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Table 11.5.2.25: CCS Configuration Parameters Information Element Coding Standard 



CTA-Coarse Timing Advance Value (Octet 2, 3 and bit 8 of Octet 4) 

Tlie Coarse Timing Advance value is in the range of to 260 ms encoded in Forward Bit 
Period units of 48/13 usee. The most significant digit is in bit 8 of octet 2, the middle digits 
are in octet 3 while the least significant digit is in bit 8 of octet 4. See GMR-2 05.010 [27] for 
further details. 

S-RACH Configuration (Octet 4, bits 7 ,6 and 5) 

The S-RACH configuration parameter specifies the size of the S-RACH slot in terms of 
Frame Periods (60/13 msec) used on a S-RACH Return Subcarrier Frequency. 



Bits 








7 


6 


5 













9 Frame Periods per S-RACH slot 








1 


2 Frame Periods per S-RACH slot 





1 





3 Frame Periods per S-RACH slot 





1 


1 


4 Frame Periods per S-RACH slot 


1 








5 Frame Periods per S-RACH slot 


1 





1 


6 Frame Periods per S-RACH slot 


1 


1 





7 Frame Periods per S-RACH slot 


1 


1 


1 


8 Frame Periods per S-RACH slot 



S-RACH transmissions are at the beginning of the S-RACH slot on the S-RACH Return 
Subchannel Frequency. 

S-BCCH Power Reference (Octet 4, bits 4, 3, 2, 1) 

The S-BCCH Power Reference parameter specifies the power of the S-BCCH with respect to 
a nominal TCH channel. It is a binary number with MSB in bit 4. The units are 0.2 dB. 

SB-RACH (Octet 5) 

The subcarrier frequencies for CCCH-0, CCCH-Ext-1 , CCCH-Ext-2 and CCCH-Ext-3, are 
encoded in SB-RACH-0, SB-RACH-1, SB-RACH-2, and SB-RACH-3, respectively. The 
mapping between forward TNs and return TNs (sub-channel frequencies) is shown in 
GMR-2 05.002 [23], table 5.3.4. Each parameter is a binary number representing the actual 
subcarrier from the set 0, 1 , 2, and 3. The MSB for the SB-RACH-0 parameter is in octet 5 bit 
8, the MSB for the SB-RACH-1 parameter is in octet 5 bit 6, the MSB for the SB-RACH-2 
parameter is in octet 5 bit 4 and the MSB for the SB-RACH-3 parameter is in octet 5 bit 2. 



1 1 .5.2.46 Forward epoch delay 



The Forward Epoch Delay information element provides the value of the time offset of the ground transmission relative 
to the ground system time for the basic TN structure. The Coarse Timing Advance (see clause 11. 5. 2.45), and the 
Forward Epoch Delay are required to establish system time at the MES for transmissions in the MES - Network 
direction. 

The information is coded as shown in figure 11.5.2.26 and table 11.5.2.26. 
The Forward Epoch Delay information element is a type 3 element with 3 octets. 

8 7 6 5 4 3 2 1 



Forward Epoch Delay lEI 



CO (low) 



FSG 



FO 



CO (high) 



Spare 



octet 1 
octet 2 
octet 3 



Figure 11.5.2.26: Forward Epoch Delay Information Element Format 
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Table 11.5.2.26: Forward Epoch Delay Information Element Coding Standard 



co-Channel Offset (Octet 2 and 3) 

The Channel Offset value is the binary representation of the number of Forward Burst 
Periods that the ground network applied to the transmission. The Channel Offset value is in 
the range of to 407 (8 x 51-1) Forward Slot Periods (15/26 ms). The most significant digit is 
in bit 8 of octet 2 while the least significant digit is in bit 8 of octet 3. 

FSG-Forward Stagger Group (Octet 3) 

The Forward Stagger Group parameter specifies the number of "quarter" burst periods that 
the ground network applied to the transmission. The value is either 0, 1 , 2, or 3. The most 
significant digit is in bit 7 of octet 3 while the least significant digit is in bit 6 of octet 3. 

FO-Frequency Offset (Octet 3) 

The Frequency Offset parameter specifies the offset that is applied to the basic channel plan 
in the spotbeam. Binary indicates the nominal channel plan. Binary one indicates the offset 
is applied to the nominal channel plan. 



1 1 .5.2.47 HPA/HMS Configuration 



The purpose of HPA/HMS Configuration information element is to provide the definition of the HPA/HMS 
configuration for the S-HPACH and S-HMSCH channels. 

The HPA Configuration information element is coded as shown if figure 11.5.2.27 and table 11.5.2.27. 
The HPA Configuration is a type 3 information element with 6 octets length. 

8 7 6 5 4 3 2 1 



BLKS_R 
ES 



HPA Configuration lEI 



SB HPA EXT RES 



HPA Timer (high) 



HPA Timer (low) 



S-HMSCH Power Reference 



M-MO 
M-MT 



octet 1 
octet 2 

octet 3 
octet 4 
octet 5 
octet 6 



Figure 11.5.2.27: HPA Configuration Information Element Format 
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Table 11.5.2.27: HPA Configuration Information Element Coding Standard 



BLKS_RES (octet 2, bit 8) 

SB_HPA_BLKS_RES specifies the number of S-HPACH Subgroups in each TN. if zero, it 
specifies 5 paging subgroups per TN and if it is one, it specifies 8 paging subgroups per TN. 

SB_HPA_EXT_RES (octet 2, bits 7 to 3) 

A bit map that specifies which TNs are used for HPA. If the following bits are set to one, the 
specified TNs are used for HPA: 

bit TN 

7 4 

6 2 

5 3 

4 5 

3 6 

HPA Timer (Octet 2 and 3) 

This parameter specifies the binary value of the amount of time, in steps of one second, the 
user has to respond to the last page attempt in a sequence of page attempts before the 
paging process is terminated. See table 4.3-2 and figure 4.3-3 for how to set HPA Timer. The 
most significant digit is in bit 2 of octet 2 with the least significant digit is in bit 1 of octet 3. 

S-HMSCH Power Reference (Octet 4) 

The S-HMSCH Power Reference parameter specifies the level of the S-HMSCH signal with 
respect to a nominal TCH channel. It is a binary number with MSB in bit 8. The units are 0.2 
dB. 

M-MO (Octet 5) 

This parameter specifies the amount of time that the Originating MES transmits the FTC 
bursts for a single hop MES connection. It is a binary number with MSB in bit 8. It has units 
of 0.5 seconds. 

M-MT (Octet 5) 

This parameter specifies the amount of time that the Terminating MES transmits the FTC 
bursts for a single hop MES connection. It is a binary number with MSB in bit 8. It has units 
of 0.5 seconds. 



1 1 .5.2.48 Location area code 

The purpose of Location Area Code information element is to provide an unambiguous identification of spotbeams and 
primary gateway servicing the spotbeam within the area covered by the system. 

The Location Area Code information element is coded as shown if figure 11.5.2.28 and table 11.5.2.28. 
The Location Area Code is a type 3 information element with 3 octets length. 



Location Area Code I El 



octet 1 
octet 2 
octet 3 



Spotbeam ID (high) 



Spotbeam ID (low) 



Figure 11.5.2.28: Location Area Code Information Element Format 
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Table 11.5.2.28: Location Area Code Information Element Coding Standard 



Spotbeam ID (octets 2 and 3) 

The Spotbeam ID is a binary number used to identify eitlier a single spotbeam or a beam 
pair for inclined orbit operations. The most significant bit is Octet 2, bit 8, while the least 
significant bit is bit 1 of Octet 3. 

If a LAI has to be deleted, then all bits of the LAC shall be set to one with the exception of 
the least significant bit which shall be set to zero. If a SIM is inserted in a MES Equipment 
with the location are code containing all zeros, then the terminal shall recognize this LAC as 
part of a deleted LAI. 



11.5.2.49 Beam pair LU timer 

The purpose of Beam Pair LU Timer information element is to provide an unambiguous identiiication of spotbeams and 
primary gateway servicing the spotbeam within the area covered by the system. 

The Beam Pair LU Timer information element is coded as shown in figure 1 L5.2.29 and table 1 1.5.2.29. 
The Beam Pair LU Timer is a type 3 information element with 2 octets length. 



Beam Pair LU Timer lEI 



octet 1 
octet 2 



T3212a 
Time-Out Value 



Figure 11.5.2.29: Beam Pair LU Timer Information Element Format 
Table 11.5.2.29: Beam Pair LU Timer Information Element Coding Standard 



T 321 2a Time-Out Value (octet 2) 

The T 321 2a time-out value field is coded as the binary representation of the time-out value 
for updating in decihours. 



Range: 1 to 255 

The value is used for infinite time-out value (i.e. updating shall not be used in the spotbeam 
type). 



1 1 .5.2.50 Paging request reference 

The purpose of the Paging Request Reference information element is to provide a method to uniquely identify MES 
responses to paging messages. 

The Request Reference information element is coded as shown in figure 11.5.2.30 and table 11.5.2.30. 
The Request Reference is a type 3 information element with 3 octets length. 

8 7 6 5 4 3 2 1 

I Request Reference lEI octet 1 

Transaction ID (high) octet 2 

Transaction ID (low) ~| octet 3 

Figure 11.5.2.30: Request Reference Information Element Format 
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Table 11.5.2.30: Request Reference Timer Information Element Coding Standard 



Transaction Id (octet 2 and 3) 

A 1 6 bit binary word generated by tine network to uniquely identify MES responses to paging 
messages. 

Bit 8 of octet 2 is the MSB. Bit 1 of octet 3 is the LSB 



11.5.2.51 



(Deleted) 



1 1 .5.2.52 Satellite Frequency List 

The purpose of the SatelUte Frequency Information Element is to provide an active frequency list and a pending 
frequency list. The active frequency list provides the CCS (control channel) frequency used by each spotbeam. For the 
active list, the Satellite Frequency IE is coded as shown in figure 11.5.2.31a and table 11.5.2-31. 

The pending frequency list provides spotbeam number and new CCS frequency for each spotbeam. For the pending list, 
the Satellite Frequency IE is coded as shovm in figure 1 1.5.2.3 lb and table 1 1.5.2.32. 

The Satellite Frequency is a type 3 information element with 22 octet length. 

8 7 6 5 4 3 2 1 



Frequency List Type 



Satellite Frequency I El 



SubUst Number 



LARFCN (active list) 



LARFCN 1 (active list) 



octet 1 
octet 2 
octet 3 
octet 4 



LARFCN 18 (active list) 



LARFCN 19 (active list) 



octet 21 
octet 22 



Figure 11.5.2.31a: Satellite Frequency Information Element/ Active Frequency List 
Table 11.5.2.31: Satellite Frequency Information Element/ Active Frequency List 



Frequency List Type (Octet 2, bits 8 to 5)Fill with All 'O's to Indicate Active Frequency List 
Sublist Number (Octet 2, bits 4 to 1 ) 

There is an assumed order to the list of frequencies sent in this message. The number of spotbeams 
are numbered from 1 to 1 40. Each spotbeam has an associated CCS frequency. The entire list is 
divided into groups of twenty using the equation, {spotbeam number-1} mod 20 and inserted into the 
appropriate octets. The sublist number is , {spotbeam number-1} div 20. Hence the absolute 
spotbeam number and associated frequency can be reconstructed from the sublist number and the 
order of the frequency in the lEI. The sublist number is a 4 bit binary number with MSB in bit 4. 

LAFRCN (Octet 3 to 22) 

Binary 255 indicates a spotbeam that does not have a CCS frequency 
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Satellite Frequency I El 



Frequency List Type 



Sparc 



Spotbeam Number (pending list) 



LARFCN (pending list) 



octet 1 
octet 2 
octet 3 
octet 4 



Spotbeam Number9 (pending list) 



Pending LARFCN 9 (pending list) 



octet 21 
octet 22 



Figure 11.5.2.31b: Satellite Frequency Information Element/Pending Frequency List 
Table 11.5.2.32: Satellite Frequency Information Element/Pending Frequency List 



Frequency List Type (Octet 2, bits 8 to 5) 
Fill With All 'I's to Indicate Pending Frequency List 
Spare Bits (Octet 2, bits 4 to 1) 
All 'I's. 

Spotbeam Number x (Odd octets, 3 up to octet 21) 

The binary presentation of a spotbeam number, from 1 to 140. 
Pending LAFRCN x (Even octets, 4 up to octet 22) 

Pending new LARFCN for the spotbeam with the Number x. 

For the rest of the Octets : If the pending changes do not fill the whole IE then they should 
be coded as hexadecimal 'EE'. 



1 1 .5.2.52.1 Implementation Requirement 

The implementation of the creation and maintenance of the CCS list in the network and in the User Terminals shall be 
as follows: 

a) The System Information type 8 message, indicating a Pending Frequency List, shall only be sent by the network 
when changes in the current list are planned in the system. It is suggested that the network start sending this list one 
week before performing the changes. 

b) (Deleted) 

c) The network shall perform aU changes, announced in a Pending Frequency List with a particular Sequence Number 
(in the H-BCCH Version Number message) at the same time. 

d) The User Terminal shall, upon receiving a new Pending Frequency List, associate the announced pending 
LARFCNs to the active ones for the Spotbeams contained in the list. The associated LARECNs shall be scaimed in 
addition to the active ones, until they become active. 
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1 1 .5.3 Mobility IVIanagement information elements 

For the Mobility Management information elements listed below, the default coding of the information element 
identifier bits is summarized in table 11.5.3.1. 

Table 11.5.3.1: Information Element Identifier Coding for Mobility Management Information Elements 















Reference 


8 7 


6 


5 4 3 


2 


1 




clause 












Type 1 Info Elements 




1 





1 






Note 




1 1 












Note 




1 1 


1 









Note 




1 


1 









Type 2 info elements 










1 






Follow-on Proceed 


11.5.3.7 












Type 3 and 4 info elements 




1 











1 


Note 




1 








1 





Note 




1 





1 








Note 




All other values are reserved 










NOTE: Reserved 













1 1 .5.3.1 Authentication parameter RAND 

The purpose of the Authentication Parameter RAND information element is to provide the MES with a non-predictable 
number to be used to calculate the authentication response signature SRES and the ciphering key Kc. 

The Authentication Parameter RAND information element is coded as shown in figure 11.5.3.1 and table 11.5.3.2. 

The Authentication Parameter RAND is a type 3 information element with 17 octets length. 

8 7 6 5 4 3 2 1 



Authentication Parameter RAND lEI 


RAND 


value 



octet 1 
octet 2 



octet 17 



Figure 11.5.3.1: Authentication Parameter RAND Information Element Format 
Table 11.5.3.2: Authentication Parameter RAND Information Element Coding Standard 



RAND value (octet 2, 3,... and 17) 

The RAND value consists of 128 bits. Bit 8 of octet 2 is the most significant bit 
while bit 1 of octet 17 is the least significant bit. 



1 1 .5.3.2 Authentication parameter SRES 

The purpose of the authentication parameter SRES information element is to provide the network with the 
authentication response signature calculated in the MES. 

The Authentication Parameter SRES information element is coded as shown in figure 11.5.3.2 and table 11.5.3.3. 
The Authentication Parameter SRES is a type 3 information element with 5 octets length. 
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Authentication Parameter SRES lEI 



SRES value 



octet 1 
octet 2 

octet 5 



Figure 11.5.3.2: Authentication Parameter SRES Information Element Format 
Table 11.5.3.3: Authentication Parameter SRES Information Element Coding Standard 



SRES value (octet 2, 3, 4 and 5) 

Tine SRES value consists of 32 bits. Bit 8 of octet 2 is the most significant bit 
while bit 1 of octet 5 is the least significant bit. 



1 1 .5.3.3 CM service type 

The purpose of the CM Service Type information element is to specify which service is requested from the network. 
The CM Service Type information element is coded as shown in figure 11.5.3.3 and table 11.5.3.4. 
The CM Service Type is a type 1 information element 

8 7 6 5 4 3 2 1 



CM Service Type lEI 



service type 



octet 1 



Figure 11.5.3.3: CM Service Type Information Element Format 
Table 11.5.3.4: CM Service Type Information Element Coding Standard 



Service type (octet 1 ) 






Bits 








4 3 


2 


1 










1 


MES originating call establishment 








or packet mode connection establishment 





1 





Emergency call establishment 


1 








Short Message Service 


1 








Supplementry service activation 


All other values are reserved 



1 1 .5.3.4 Identity type 

The purpose of the Identity Type information element is to specify which identity is requested. 
The Identity Type information element is coded as shown in figure 11.5.3.4 and table 11.5.3.5. 
The Identity Type is a type 1 information element. 



8 


7 6 


5 


4 


3 2 1 




Identity Type lEI 




spare 


Type of Identity 


octet 1 



Figure 11.5.3.4: Identity Type Information Element Format 
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Table 11.5.3.5: Identity Type Information Element Coding Standard 



Type of Identity (octet 1) 




Bits 






3 2 


1 







1 


IMSI 


1 





IMEI 


1 


1 


IMEISV 


1 





Reserved 


All other values are reserved 



1 1 .5.3.5 Location updating type 

The purpose of the Location Updating Type information element is to indicate whether a normal updating or a periodic 
updating is wanted. It may also indicate that a follow-on request has been received from the MES CM layer. 

The Location Updating Type information element is coded as shown in figure 11.5.3.5 and table 1 1.5.3.6. 

The Location Updating Type is a type 1 information element. 



8 7 6 5 


4 


3 


2 1 




Location Updating Type lEI 


FOR 





LUT 


octet 1 






spare 







Figure 11.5.3.5: Location Updating Type Information Element Format 
Table 11.5.3.6: Location Updating Type Information Element Coding Standard 



LUT (octet 1) 




Bits 




2 1 







Normal Location Updating 


1 


Periodic Location Updating 


1 


Reserved 


1 1 


Reserved 


FOR (octet 1 




The Follow-On Request bit (FOR) is coded as follows 


Bit 




4 







No follow-on request pending 


1 


Follow-on request pending 



1 1 .5.3.6 Reject cause 

The purpose of the Reject Cause information element is to indicate the reason why a request from the MES is rejected 
by the network. 

The Reject Cause information element is coded as shown in figure 1 1.5.3.6 and table 1 1.5.3.7. 
The Reject Cause is a type 3 information element with 2 octets length. 

8 7 6 5 4 3 2 1 



Reject Cause I El 



Reject Cause Value 



octet 1 
octet 2 



Figure 11.5.3.6: Reject Cause Information Element Format 
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Table 11.5.3.7: Reject Cause Information Element Coding Standard 

Reject cause value (octet 2) 
Bits 



8 


7 


6 


5 


4 


3 


2 


1 






















1 





IMSI unknown in HLR 




















1 


1 


Illegal MES 

















1 








IMSI unknown in VLB 

















1 





1 


IIVIEI not accepted 

















1 


1 





Illegal ME-MES 

















1 


1 


1 


Local Transmit Disable by the network 














1 





1 


1 


PSMN Not allowed 














1 


1 








Location Area not allowed 














1 


1 





1 


National roaming not allowed in this location area 











1 











1 


Network failure 











1 





1 


1 





Congestion 








1 

















Service option not supported 






















1 


Requested service option not subscribed 



















1 





Service option temporarily out of order 
















1 


1 





Call cannot be identified 









1 


1 


1 


1 


1 


Semantically incorrect message 
























Invalid mandatory information 





















1 


IVIessage type non-existent or not implemented 


















1 





Message type not compatible with the protocol state 


















1 


1 


Information element non-existent or not implemented 















1 








Conditional IE error 















1 





1 


Message not compatible with the protocol state 












1 


1 


1 


1 


Protocol error, unspecified 



Any other value received by the MES shall be treated as 0010 0010, 'Service option temporarily 
out of order'. Any other value received by the network shall be treated as Oil 11 11 , 'Protocol 
error, unspecified'. 

NOTE: The listed reject cause values are described in Annex G 



1 1 .5.3.7 Follow-On proceed 

The purpose of the Follow-on Proceed information element is to indicate that a MM connection may be established on 
an existing RR connection. 

The Follow-on Proceed information element is coded as shown in figure 11.5.3.7. The Follow-on Proceed is a type 2 
information element. 



8 



7 



6 



5 4 



3 



2 



1 



Follow-On Proceed I El 



octet 1 



Figure 11.5.3.7: Follow-On Proceed Information Element Format 
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1 1 .5.4 Call Control information elements 

For the call control information elements listed below, the default coding of the information element identifiers is 
defined in table 11.5.4.1. 



Table 11.5.3.1: Information Element Identifier Coding for Call Control Information Elements 



















Reference 


8 7 


6 


5 


4 


3 


2 


1 




clause 


1 














Type 1 info elements 










1 










Shift 


1 1 .5.4.2 and 


















1 1 .5.4.3 





1 


H 
1 










Note 




H 
1 





H 
1 










Repeat indicator 


1 1 .5.4.22 


1 


1 


1 










Type 2 info elements 










(J 


(J 


(J 


(J 


Mode data 


1 1 .D.4.iy 

















1 


CLIR Suppression 


1 1 .0.4.1 1 a 














1 





CLIR Invocation 


11.5.4.11b 














1 


1 


Reverse call setup direction 


1 1 .5.4.22a 

















Type 3 and 4 info elements 
















1 








Bearer capability 


1 1 .5.4.5 











1 











Cause 


1 1 .5.4.1 1 


u 


U 


H 


u 




U 


u 


Note 




u 


U 


H 

1 


u 




U 


H 

1 


Call Control Capabilities 


•i -i C A Co 

1 1 .o.4.oa 








1 


1 


] 








Facility 


1 1 .5.4.15 








1 


1 




1 





Progress Indicator 


11.5.4.21 





1 








1 








Auxiliary states 


11.5.4.4 


U 


1 





U 




1 


1 


Note 







1 





1 










Keypad facility 


11.5.4.17 





1 


1 













Signal 


11.5.4.23 










1 










Connected number 


11.5.4.13 










1 







1 


Connected subaddress 


11.5.4.14 







1 


1 










Calling party BCD number 


11.5.4.9 







1 


1 







1 


Calling party subaddress 


11.5.4.10 







1 


1 




1 





Called party BCD number 


11.5.4.7 









1 







1 


Called party subaddress 


11.5.4.8 






1 


1 










Low layer compatibility 


11.5.4.18 






1 


1 







1 


High layer compatibility 


11.5.4.16 






1 


1 




1 





User - user 


1 1 .5.4.25 






1 


1 




1 


1 


SS version indicator 


1 1 .5.4.24 


NOTE: 


Reserved 















11.5.4.1 Extensions of codesets 

There is a certain number of possible information element identifier values using the formatting rules described in 
clause 1 1.5: 128 from the Type 3 & 4 information element format and at least 8 from the Type 1 & 2 information 
element format. 

One value in the Type 1 format is specified for shift operations described below. One other value in both the Type 3 & 
4 and Type 1 format is reserved. This leaves 133 information element identifier values available for assignment. 

It is possible to expand this structure to eight codesets of 133 information element identifier values each. One common 
value in the Type 1 format is employed in each codeset to facilitate shifting ftom one codeset to another. The contents 
of this shift information element identifies the codeset to be used for the next information element or elements. The 
codeset in use at any given time is referred to as the "active codeset." By convention, codeset is the initially active 
codeset. 

Two codeset shifting procedures are supported: locking shift and non-locking shift. 
Codeset 5 is reserved for information elements reserved for national use. 

Codeset 6 is reserved for information elements specific to the local network (either public or private). 
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Codeset 7 is reserved for user-specific information elements. 

The coding rules specified in clause 11.5 shall apply for information elements belonging to any active codeset. 

Transitions from one active codeset to another (i.e., by means of the locking shift procedure) may only be made to a 
codeset with a higher numerical value than the codeset being left. 

An information element belonging to codeset 5, 6 or 7 may appear together with information elements belonging to 
codeset 0, by using the non-locking shift procedure (see clause 11.5.4.3). 

A user or network equipment shall have the capability to recognize a shift information element and to determine the 
length of the following information element, although the equipment need not be able to interpret and act on the content 
of the information element. This enables the equipment to determine the start of the subsequent information element. 

Only use of Codeset is required. 

1 1 .5.4.2 Locking shift procedure (Not applicable to current GMR-2 system - specified 
for future use) 

The locking shift procedure employs an information element to indicate the new active codeset. The specified codeset 
remains active until another locking shift information element is encountered which specifies the use of another codeset. 
For example, codeset is active at the start of message content analysis. If a locking shift to codeset 5 is encountered, 
the next information elements will be interpreted according to the information element identifiers assigned in codeset 5, 
until another shift information element is encountered. This procedure is used only to shift to a higher order codeset 
than the one being left. 

The locking shift is valid only within that message which contains the locking shift information element. At the start of 

every message content analysis, the active codeset is codeset 0. 

The locking shift information element uses the Type 1 information element format and coding shown in figure 1 1.5.4. 1 
and table 11.5.4.2. 



8 


7 


6 


5 


4 


3 


2 


1 




Shift Identifier 





New Codeset 
Identification 



"0" in this position indicates locking shift 



Figure 11.5.4.1: Locking Shift Element Format 



Table 11.5.4.2: Locking Shift Element Coding Standard 



Codeset identification (octet 1) 




bits 3 


2 


1 















not applicable 










1 






to 1 








reserved 




1 





1 


codeset 5 : 


information elements for national use 


1 


1 





codeset 6 : 


information elements specific to the local 










network (either public or private) 


1 


1 


1 


codeset 7 : 


user-specific informative elements 
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1 1 .5.4.3 Non-locking shift procedure (Not applicable to current GMR-2 system - 
specified for future use) 

The non-locking shift procedure provides a temporary shift to the specified lower or higher codeset. The non-locking 
shift procedure uses a Type 1 information element to indicate the codeset to be used to interpret the next information 
element. After the interpretation of the next information element, the active codeset is again used for interpreting any 
following information elements. For example, codeset is active at the beginning of message content analysis. If a non- 
locking shift to codeset 6 is encountered, only the next information element is interpreted according to the information 
element identifiers assigned in codeset 6. After this information element is interpreted, codeset will again be used to 
interpret the following information elements. A non-locking shift information element indicating the current codeset 
shall not be regarded as an error. 

A locking shift information element shall not follow directly a non-locking shift information element. If this 
combination is received, it shall be interpreted as though a locking shift information element had been received. 

The non-locking shift information element uses the Type 1 information format and coding shown in figure 11.5.4.2 and 
table 11.5.4.3. 



8 


7 6 5 


4 


3 2 1 




Shift Identifier 


1 


Temporary Codeset 
Identification 



"1" in this position indicates non-locking shift 



Figure 11.5.4.2: Locking Shift Element Format 
Table 11.5.4.3: Locking Shift Element Coding Standard 



Codeset identification (octet 1) 



bits 3 


2 


1 















codeset 


(initially active) 








GMR-2 information elements 








1 






to 1 








reserved 




1 





1 


codeset 5 : 


information elements for national use 


1 


1 





codeset 6 : 


information elements specific to the local 










network (either public or private) 


1 


1 


1 


codeset 7 : 


user-specific informative elements 



1 1 .5.4.4 Auxiliary states 

The purpose of the auxiliary states information element is to describe the current status of the auxiliary states of a call in 
the call control states "active" and "mobile originating modify" (See GMR-2 04.083 [21] and GMR-2 04.084 [22]). 

The auxiliary states information element is coded as shown in figure 11.5.4.3, table 11.5.4.4 and table 11.5.4.5. 

The auxiliary states is a Type 4 information element with 3 octets length. 



8 


7 


6 5 


4 3 


2 1 




1 Auxilary States lEI 


octet 1 


Length of Auxilary states contents 


octet 2 


1 








hold aux. 


MPTY aux. 


octet 3 


ext 




spare 


state 


state 





Figure 11.5.4.3: Auxilary States Information Element Format 
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Table 11.5.4.4: Auxilary States Information Element Coding Standard 



Hold auxiliary state (octet 3) 



Bits 








4 


3 












idle 


Note 1 





1 


liold request 


Note 1 


1 





call held 


Note 1 


1 


1 


retreive request 


Note 1 



NOTE 1 : These states are defined in GMR-2 04.083 [21 ] 

NOTE: Only the state "hold request" shall be processed by the MSG and the network 
Table 11.5.4.5: Auxilary States Information Element Coding Standard (Not supported by MSC) 



Multi party auxiliary state (octet 3) 



Bits 








2 


1 












idle 


Note 2 





1 


MPTY request 


Note 2 


1 





call in MPTY 


Note 2 


1 


1 


split request 


Note 2 



NOTE 2: These states are defined in GMR-2 04.084 [22] 



1 1 .5.4.5 Bearer capability 

The purpose of the bearer capability information element is to describe a bearer service. The use of the bearer capabiUty 
information element in relation to compatibility checking is described in Annex B. 

The bearer capability information element is coded as shown in figure 1 1.5.4.4 and tables 1 1.5.4.6 through 1 1.5.4. 13. 

The bearer capability is a Type 4 information element with a minimum length of 3 octets and a maximum length of 10 
octets. 



8 


7 


6 


5 


4 


3 


2 


1 




1 Bearer capability lEI 


octet 1 


Length of the bearer capability contents 


octet 2 


1 


radio channel 


coding 


transfer 


information transfer 


octet 3 


ext 


requirement 


standard 


mode 




capability 






1 





structure 


duplex 


configura 


NIRR 


establish 


octet 4* 


ext 


spare 






mode 


tion 




ment 




1 








rate 




signalling 




octet 5* 


ext 


access 


id. 


adaption 


access protocol 




0/1 





1 




User information 




sync/ 


octet 6* 


ext 


layer 1 


id. 




layer 1 protocol 




async 




0/1 


number 


negotiati 


number 




User rate 




octet 6a* 


ext 


stop bits 


on 


data bits 












0/1 


Intermediate 


NIC 


NIC 




Parity 




octet 6b* 


ext 


rate 


onTX 


on RX 










1 


connection 






Modem type 




octet 6c* 


ext 


element 














1 


1 







User information 




octet 7* 


ext 


layer 


2 id. 




layer 2 protocol 







Figure 11.5.4.3: Bearer Capability Information Element Format 
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Table 11.5.4.6: Bearer Capability Information Element Coding Standard 



Radio channel requirement (octet 3) 
Network to MES direction 

Bits 6 and 7 are spare bits 

Radio cliannel requirement (octet 3) 
MES to Network direction 

Bits IVISC only MES and GSC only 
7 6 

Reserved Reserved 

1 Full rate channel Basic rate 

1 Dual rate / Half rate preferred Dual rate / Enhanced rate preferred 
1 1 Dual rate / Full rate preferred Dual rate / Basic rate preferred 

Coding Standard (octet 3) 

Bit 

5 

GSM / system standardization as described below 

1 Reserved 

Transfer mode (octet 3) 

Bit 

4 

circuit mode 

1 packet mode 

Information transfer capability (octet 3) 



Bits 








3 


2 


1 













speech 








1 


unrestricted digital information 





1 





3.1 kHz audio, ex PLMN 





1 


1 


facsimile group 3 


1 


1 


1 


reserved, to be used in the network 



All other values are reserved 
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Table 11.5.4.7: Bearer Capability Information Element Coding Standard 



Structure (octet 4) 

Bits 

6 5 

service data unit integrity 

1 1 unstructured 

All other values are reserved 

Duplex mode (octet 4) 

Bit 

4 

half duplex 

1 full duplex 

Configuration (octet 4) 

Bit 

3 

point to point 

All other values are reserved 
NIRR (octet 4) 

(Negotiation of Intermediate Rate Requested) 

Bit 

2 

No meaning is associated with this value 

1 Data up to and including 4.8 kb/s, full rate, non- 
transparent, 6kb/s radio interface rate is requested 

Establishment (octet 4) 

Bit 

1 

demand 

All other values are reserved 
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Table 11.5.4.8: Bearer Capability Information Element Coding Standard 



Access Identity (octet 5) 

Bits 

7 6 

octet identifier 

All other values are reserved 

Rate adaptation (octet 5) 

Bits 

5 4 

no rate adaptation 

1 V. 11 0/X.30 [54] rate adaptation 

1 ITU-T Recommendation X.31 [55] flag stuffing 

All other values are reserved 
Signalling access protocol (octet 5) 



Bits 








3 


2 


1 










1 


1.440 [39] and 1.450 [40] 





1 





X.21 [51] 





1 


1 


X.28 [53] - dedicated PAD, individual NUI 


1 








X.28 [53] - dedicated PAD, universal NUI 


1 





1 


X.28 [53] - non dedicated PAD 


1 


1 





X.38 



All other values are reserved 



Table 11.5.4.9: Bearer Capability Information Element Coding Standard 



Layer 1 identity (octet 6) 

Bits 

7 6 

1 octet identifier 

All other values are reserved 

User information Layer 1 protocol (octet 6) 
Bits 

5 4 3 2 

default Layer 1 protocol 

All other values are reserved 

Synchronous / asynchronous (octet 6) 

Bit 

1 

synchronous 
J asynchronous 
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Table 11.5.4.10: Bearer Capability Information Element Coding Standard 



Number of Stop Bits (octet 6a) 

Bit 

7 

1 bit (This value is also used in the case of synchronous mode) 

1 2 bits 



Negotiation (octet 6a) 

Bit 

6 

in-band negotiation is not possible 

see Note 



All other values are reserved 



Number of data bits excluding parity bit if present (octet 6a) 

Bit 

5 

7 bits 

1 8 bits (this value is also used in the case of bit orientated protocols) 



User rate (octet 6a) 
Bits 

4 3 2 1 

11 2.4 kbit/s Recommendation X.1 and V.1 10 [50] 

1 4.8 kbit/s Recommendation X.1 and V.1 10 [50] 

10 1 9.6 kbit/s Recommendation X.1 and V.1 10 [50] 



All other values are reserved 



For facsimile group 3 calls the user rate indicates the first and maximum speed the 
MES is using. 

NOTE: See Recommendation V.110 [50] and X.30 [54] 
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Table 11.5.4.11: Bearer Capability Information Element Coding Standard 



Intermediate rate (octet 6b) 



Bits 






7 


6 










Reserved 





1 


Reserved 


1 





8 kbits/s 


1 


1 


1 6 l<bits/s 



Networl< independent clock (Nl C) on transmission (Tx) (octet 6b) 

(See Rec V.1 10 [50] and X.30 [54]) 

Bit 

5 

Does not requires to send data with network independent clock 

1 Requires to send data with network independent clock 

Network independent clock (Nl C) on reception (Rx) (octet 6b) 

(See Rec V.1 10 [50] and X.30 [54]) 

Bit 

4 

Cannot accept data with network independent clock (i.e. sender does not 
support this optional procedure 

1 Can accept data with network independent clock (i.e. send does support this 
optional procedure) 

Parity information (octet 6b) 



Bits 








3 


2 


1 













odd 





1 





even 





1 


1 


none 


1 








forced to 


1 





1 


forced to 1 



All other values are reserved 
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Table 11.5.4.12: Bearer Capability Information Element Coding Standard 



Connection element (octet 6c) 



Bits 




7 


6 











1 


1 





1 


1 



transparent 
non transparent (RbP) 
botii, transparent preferred 
botli, non-transparent preferred 



Tine requesting end (e.g. tlie one sending tlie SETUP message) sliould use tlie 4 
values depending on its capabilities to support the different modes. The answer- 
ring party shall only use the codings 00 or 01, based on its own capabilities and the 
proposed choice if any. 

If both MES and network support both transparent and non transparent, priority should 

be given to the IVIES preference. 



Modem type (octet 6c) 
Bits 



5 


4 


3 


2 


1 



















none 














1 


V.21 [44] 











1 





V.22 [45] 











1 


1 


V.22 [46] bis 








1 








V.23 [47] 








1 





1 


V.26 [48] ter 








1 


1 





V.32 [49] 








1 


1 


1 


modem for undefined interface 





1 











reserved 



All other values are reserved 



Table 11.5.4.13: Bearer Capability Information Element Coding Standard 



Layer 2 identity (octet 7) 

Bits 

7 6 

1 octet identifier 



All other values are reserved 



User information layer 2 protocol (octet 7) 
Bits 



5 


4 


3 


2 


1 










1 


1 





recommendation X.25 [52], link level 





1 











ISO 6429 [32], codeset (DC1/DC3) 





1 








1 


X.75 [57] layer 2 modified (teletex) 





1 





1 





videotex profile 1 





1 


1 








COPnoFICt (Character Oriented Protocol with no Flow 



Control mechanism) 



All other values are reserved 



1 1 .5.4.5.1 Static conditions for tine bearer capability IE contents 

If the information transfer capability field (octet 3) indicates "speech", octets 4 5, 6, 6a, 6b, 6c, and 7 shall not be 
included. 

If the information transfer capability field (octet 3) indicates a value different from "speech", octets 4 5, 6, 6a, 6b, and 
6c shall be included. 

If the information transfer capability field (octet 3) indicates "facsimile group 3", the modem type field (octet 6c) shall 
indicate "none". 
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The modem type field (octet 6c) shall not indicate "autobauding type 1" unless the connection element field (octet 6c) 
indicates "non transparent" (Reserved). 

1 1 .5.4.5a Call control capabilities 

The purpose of the call control capabilities information element is to identify the call control capabiUties of the user 
terminal. 

The call control capabilities information element is coded as shown in figure 11.5.4.5 and table 11.5.4.14. 
The call control capabilities is a type 4 information element with a length of 3 octets. 

8 7 6 5 4 3 2 1 



Call Control Capabilities lEI 



Length of Call Control Capabilities Contents 



spare 



DTMF 



octet 1 
octet 2 
octet 3 



Figure 11.5.4.5: Call Control Capabilities Information Element Format 
Table 11.5.4.14: Call Control Capabilities Information Element Coding Standard 



DTMF (octet 3) 

Bit 

1 

This value is reserved for the earlier versions of the protocol 

1 This value indicates that the user terminal supports DTMF as specified 
in clause 6.3.3 of the present document 



1 1 .5.4.6 Call state 

The purpose of the call state information element is to describe the current status of a call, (see clause 6.1). 
The call state information element is coded as shown in figure 11.5.4.6 and table 11.5.4.15. 
The call state is a type 3 information element with 2 octets length. 

8 7 6 5 4 3 2 1 



1 Call State IE! 


Coding 
standard 


call state value (coded in binary) 



octet 1 
octet 2 



Figure 11.5.4.6: Call State Information Element Format 
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Table 11.5.4.15: Call State Information Element Coding Standard 



Coding standard (octet 2) 



Bits 






8 


7 


standardized coding as described in 








ITU-T Recommendation. Q.931 





1 


reserved for other International standards 


1 





national standard 


1 


1 


standard defined for tlie GSIVl/System PLIVINS as described below 



Coding standards other than "1 1 - Standard defined for the GSM PLMNS'T shall not be used If the call 
state can be represented with the GSM/system standardized coding. 

The MES or Network need not support any other coding standard than "1 1 - Standard defined for the 
GSM/system PLMNS". 

If a call state IE indicating a coding standard not supported by the receiver Is received, call state 
"active" shall be assumed. 

Call state value (octet 2) 
Bits 



6 


5 


4 


3 


2 


1 
























UO-null 


NO -null 














1 





U0.1 - MM connection pending 


N0.1 - MM connection pending 

















1 


U1 - call initiated 


N1 - call initiated 














1 


1 


U3 - mobile originating call 


N3 - mobile orlglnateing call 














proceeding 


proceeding 











1 








U4 - call delivered 


N4 - call delivered 











1 


1 





U6 - call present 


N6 - call present 











1 


1 


1 


U7 - call present 


N7 - call received 



















U8 - connect request 


N8 - connect request 
















1 


U9 - mobile terminating call 


N9 - mobile terminating call 














confirmed 


confirmed 













1 





U10 - active 


N10 - active 













1 


1 


U1 1 - disconnect request 












1 








U1 2 - disconnect Indication 


N1 2 - disconnect Indication 





1 







1 


1 


U19 - release request 


N19 - release request 





1 







1 





U26 - mobile originating modify 


N26 - mobile originating modify 





1 







1 


1 


U27 - mobile terminating modify 


N27 - mobile terminating modify 





1 




1 










N28 - connect Indication 



NOTE: Only "1 1 " shall be used as the "Coding standard" value and the Call States U26, U27, N26, 
N27 are not required and supported by the network 



1 1 .5.4.7 Called party BCD number 

The purpose of the called party BCD number information element is to identify the called party. 

The called party BCD number information element is coded as shown in figure 1 1.5.4.7 and table 1 1.5.4.16. 

The called party BCD number is a type 4 information element with a minimum length of 3 octets and a maximum 
length of 13 octets. 



8 


7 6 5 


4 3 2 


1 




1 Called Party BCD Number lEI 


octet 1 




Length of called party 


BCD number contents 




octet 2 


1 


type of 


numbering plan 




octet 3 


ext 


number 


identification 






Number digit 2 


Number digit 1 


octet 4* 


Number digit 4 


Number digit 3 


octet 5* 



Note 2 



Figure 11.5.4.7: Called Party BCD Number Information Element Format 
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NOTE 1 : The number digit(s) in octet 4 precedes the digit(s) in octet 5 etc. The number digit that would be entered 

first is located in octet 4, bits 1 to 4 

NOTE 2: If the called party BCD number contains an odd number of digits, bits 5 to 8 of the last octet shall be 
filled with an end mark coded as " 1 1 11 " . 

Since the information element must contain the complete called party BCD number, there is no need for an additional 
complete indication. 

Table 11.5.4.16: Called Party BCD Number Information Element Coding Standard 

Type of number (octet 3) (Note 1) 



Bits 








7 


6 


5 













unknown (Note 2) 








1 


international number (Note 3, Note 5) 





1 





national number (Note 3) 





1 


1 


network specific number (Note 4) 


1 








dedicated access, siiort code 


1 





1 


reserved 


1 


1 





reserved 


1 


1 


1 


reserved for extension 



NOTE 1: For the definition of "number" see ITU-T Recommendation 1.330 [38] and GMR-2 03.003 [7]. 

NOTE 2: The type of number "unknown" is used when the user or the network has no knowledge of the type of 

number, e.g. international number, national number, etc. In this case the number digits field is organized 
according to the network dialling plan, e.g. prefix or escape digits might be present. 

NOTE 3: Prefix or escape digits shall not be included. 

NOTE 4: The type of number "network specific number" is used to indicate administration/service number specific 
to the serving network, e.g., used to access an operator. 

NOTE 5: The international format shall be accepted by the MSC when the call is destined to a destination in the 
same country as the MSC. 

NOTE 6: Only the values "000" (unknown), "001" (international number) and "010" (national number) shall be 
used. 

Table 11.5.4.17: Called Party BCD Number Information Element Coding Standard 

Numbering plan (octet 3) 

Number plan (applies for type of number = 000, 001, 010 and 100) 
Bits 



4 


3 


2 


1 
















unknown 











1 


ISDN / telephony numbering plan (Rec. 










[34]/E.164 [35]) 








1 


1 


data numbering plan (Rec. X.121 [58]) 





1 








telex numbering plan (Rec. F.69 [37]) 


1 











national numbering plan 


1 








1 


private numbering plan 


1 


1 


1 


1 


reserved for extension 



All other values reserved 

NOTE: only the values "000" (unknown), "001 " (ISDN / telephony numbering 
plan) shall be used. 

When a MES is the recipient of number information from the network, any incompatibility between the number digits 
and the number plan identification shall be ignored and a STATUS message shall not be sent to the network. 
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In the case of numbering plan "unknown", the number digits tield is organized according to the network dialling plan, 
e.g., prefix or escape digits might be present. 

Table 11.5.4.18: Called Party BCD Number Information Element Coding Standard 



Numbering digits (octet 4, etc.) 


Bits 






Number digit value 


4 3 


2 


1 


or 


8 7 


6 


5 






















■\ 


■\ 





1 





2 





1 


1 


3 


1 








4 


1 





1 


5 


1 


1 





6 


1 


1 


1 


7 


1 








8 


1 





1 


9 


1 


1 





* 


1 


1 


1 


# 


1 1 








a 


1 1 





1 


b 


1 1 


1 





c 


1 1 


1 


1 


used as an endmarl^ in case of an odd number of 
number digits 



1 1 .5.4.8 Called party subaddress 

The purpose of the Called party subaddress is to identify the subaddress of the called party of a call. For the definition 
of a subaddress see ITU-T Recommendation 1.330 [38] . 

The Called party subaddress information element is coded as shown in figure 1 1.5.4.8 and table 1 1.5.4.19. 

The called party subaddress is a type 4 information element with a minimum length of 2 octets and a maximum length 
of 23 octets. 



8 


7 


6 5 


4 


3 


2 


1 




Called Party Subaddress Number lEI 






Lengtln of called party 


Subaddress contents 






1 




type of 


odd/even 











ext 




subaddress 


indica. 




spare 




Subaddress information 



octet 1 
octet 2 
octet 3 

octet 4 

etc. 



Subaddress information 



Figure 11.5.4.7: Called Party Subaddress Information Element Format 
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Table 11.5.4.19: Called Party Subaddress Information Element Coding Standard 



Type of subaddress (octet 3) 
Bits 

7 6 5 

NASP(X.213/IS0 8348AD2[33]) 

1 User specified 

All other values are reserved 

Odd / even idicator 

Bit 

4 

even number of address signals 

1 odd number of address signals 

NOTE: The odd/even indicator is used when the type of subaddress is "user specified" 
and the coding is BCD. 

Subaddress information (octet 4, etc..) 

The NSAP X.213/IS08348AD2 [33] address shall be formatted as specified by octet 4 
which contains the Authority and Format Identifier (AFI). The encoding is made 

according to the "preferred binary encoding" as defined in X.213 / IS08348AD2 [33]. 
For the definition of this type of subaddress, see Rec. ITU-T Recommendation 1.334. 

A coding example is given in ANNEX A. 

For User-specific subaddress, this field is encoded according to the user specification, 
subject to a maximum length of 20 octets. When interworking with X.25 [52] networks 
BCD coding should be applied. 

NOTE: It is recommended that users apply NSAP subaddress type since this 

subaddress type allows the use of decimal, binary and IA5 characters in a 
standardized manner 



1 1 .5.4.9 Calling party BCD number 

The purpose of the calling party BCD number information element is to identify the origin of a call. 

This information element shall never be sent by the network (refer to clause 11.3.23.1, SETUP message). 

The calling party BCD number information element is coded as shown in figure 11.5.4.9 and table 11.5.4.20. 

The calling party BCD number is a type 4 information element. In the Network to MES direction, it has a minimum 
length of 3 octets and a maximum length of 14 octets. (This information element is not used in the MES to Network 
direction.) 



8 


7 6 


5 


4 3 


2 1 




1 Calling Party BCD Number lEI 


octet 1 


Length of called party 


BCD number contents 


octet 2 


0/1 


type of 




numbering plan 


octet 3 


ext 


number 




identification 




1 


presentation 








screening 


octet 3a* 


ext 


indicator 




spare 


indicator 




Number digit 2 


Number digit 1 


octet 4* 


Number digit 4 


Number digit 3 


octet 5* 



etc. 



Figure 11.5.4.9: Calling Party BCD Number Information Element Format 
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The contents of octets 3, 4, etc., are coded as shown in tables 11.5.4.16 to 11.5.4.18. The coding of octet 3a is defined in 
table 11.5.4.20. 

If the calhng party BCD number contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with an end 
mark coded as "1111". 

Table 11.5.4.20: Calling Party BCD Number Information Element Coding Standard 



Presentation indicator (octet 3a) 



Bits 






7 


6 










Presentation allowed 





1 


Presentation restricted 


1 





Number not available due to interworking 


1 


1 


Reserved 



If octet 3a is omitted the value "00 - Presentation allowed" is assumed. 

Screening indicator (octet 3a) 

Bits 

2 1 

user-provided, not screened 

1 user-provided, verified and passed 

1 user-provided, verified and failed 
1 1 network provided 

If octet 3a is omitted the value "00 - user provided, not screened" is assumed. 



11.5.4.10 Calling party subaddress 

The purpose of the Calling party subaddress is to identify a subaddress associated with the origin of a call. For the 
definition of a subaddress see ITU-T Recommendation 1.330 [38]. 

The Calling party subaddress information element is coded as shown in figure 11.5.4.10 and table 11.5.4.21. 

The Calling party subaddress is a type 4 information element with a minimum length of 2 octets and a maximum length 
of 23 octets. 



8 7 6 5 4 3 2 1 





Calling Party Subaddress lEI 


octet 1 


Length of called party subaddress contents 


octet 2 


0/1 


type of 


odd/even 











octet 3* 


ext 


subaddress 


idicat. 










subaddress information 


octet 4* 



etc. 



Figure 11.5.4.10: Calling Party Subaddress Information Element Format 
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Table 11.5.4.21: Calling Party Subaddress Information Element Coding Standard 



Type of subaddress (octet 3) 
Bits 

7 6 5 

NASP(X.213/IS0 8348AD2[33]) 

1 User specified 

All other values are reserved 

Odd / even idicator 

Bit 

4 

even number of address signals 

1 odd number of address signals 

NOTE: The odd/even indicator is used when the type of subaddress is "user specified" 
and the coding is BCD. 

Subaddress information (octet 4, etc..) 

The NSAP X.213/IS08348AD2 [33] address shall be formatted as specified by octet 4 
which contains the Authority and Format Identifier (AFI). The encoding is made 
according to the "preferred binary encoding" as defined in X.213 / IS08348AD2 [33]. 
For the definition of this type of subaddress, see ITU-T Recommendation 1.332. 

A coding example is given in ANNEX A. 

For User-specific subaddress, this field is encoded according to the user specification, 
subject to a maximum length of 20 octets. When interworking with X.25 [52] networks 
BCD coding should be applied. 

NOTE 1 : It is recommended that users apply NSAP subaddress type since this 

subaddress type allows the use of decimal, binary and IA5 characters in a 
standardized manner. 

NOTE 2: Only "000" (NSAP) and "010" (User specified) shall be accepted as values of 
the "Type of subaddress." In the case of (NSAP), octet 4, corresponding to the 
AFI field, shall have one of the following values ('36'H to '59'H). In the case of 
(User specified), octet 4 shall not be checked. Encoding of other octets of the 
subaddress shall not be checked. 



11.5.4.11 Cause 

The purpose of the cause information element is to describe the reason for generating certain messages, to provide 
diagnostic information in the event of procedural errors, and to indicate the location of the cause originator. 

Some of the cause values need not be used. The diagnostic information need not be sent and therefore, may be ignored 
if received. 

The cause information element is coded as shown in figure 11.5.4.11 and tables 11.5.4.22 and 11.5.4.23. 

The cause is a type 4 information element with a minimum length of 4 octets and a maximum length of 32 octets. 

The cause information element may be repeated in a message. 
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8 7 6 5 4 3 2 1 





Cause lEI 


octet 1 




_ength of cause contents 




0/1 


coding 





location 


octet 3 


ext 


standard 


spare 






1 




Recommendation 


octet 3a* 


ext 










1 






cause value 


octet 4 


ext 










diagnostics (if any) 


octet 5* 



octet N 



Figure 11.5.4.11: Cause Information Element Format 

If the default value applies for the recommendation field, octet 3a shall be omitted. 
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Table 11.5.4.22: Calling Party Subaddress Information Element Coding Standard 



Coding standard (octet 3) 

Bits 

7 6 

Coding as specified in ITU-T Recommendation Q.931 [43] 

1 Reserved for other international standards 

1 National Standard 

1 1 Standard defined for the GSM / PLMNS as described below and in table 1 1 .5.4.23 



Coding standards other than "1 1 - Standard defined for the GSM/system PLMNS" shall not be used if the 
cause can be represented with the GSM/system standardized coding. 

The MES or network need not support any other coding standard than "1 1 - Standard defined for the 
GSM/system PLMNS". 

If a cause IE indicating a coding standard not supported by the receiver is received, cause "intenworking, 

unspecified" shall be assumed. 



Location (octet 3) 
Bits 



4 


3 


2 


1 
















User 











1 


private network serving the local user 








1 





public network serving the local user 








1 


1 


transit network 





1 








public network serving the remote user 





1 





1 


private network serving the remote user 





1 


1 


1 


international network 


1 





1 





network beyond the interworking point 



All other values are reserved. 



Recommendation (octet 3a) 

Octet 3a shall not be included if the coding standard is coded as "1 1 - Standard defined for GSM/system 
PLMNS". 

If the coding standard is different from "1 1 - Standard defined for GSM/system PLMNS", the coding of 
octet 3a, if included, and octets 4 to N is according to that coding standard. 

Cause value (octet 4) 

The cause value is divided in two fields: a class (bits 5 through 7) and a value within the class (bits 1 
through 4). 

The class indicates the general nature of the event. 



Class (000) : normal event 

Class (001) : normal event 

Class (01 0) : resource unavailable 

Class (011): service or option not available 

Class (100) : service or option not implemented 

Class (101): invalid message (e.g. parameter out of range) 

Class (110): protocol error (e.g. unknown message) 

Class (111) : Interworking 



The cause values are listed in table 1 1 .5.4.23 below 
and defined in Annex H. 



Diagnostic(s) (octet 5) 

Diagnostic information is not available for every cause, see table 1 1 .5.4.23 below. 

When available, the diagnostic(s) is coded in the same way as the corresponding information element in 

clause 11. 

The inclusion of diagnostic(s) is optional. 
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Table 11.5.4.23: Cause Information Elements Values 



Cause 




Value 






Cause 


Cause 


Diagnostic 


Remarks 


Class 












num. 








7 


6 


5 


4 


3 


2 


1 




























1 


1. 


Unasslgned (unallocated) number 


Note 9 



















1 


1 


3. 


No route to destination 


Note 9 
















1 


1 





6. 


Channel unacceptable 















1 











8. 


Operator determined barring 












1 














16. 


Normal call clearing 


Note 9 










1 











1 


17. 


User busy 












1 








1 





18. 


No user responding 












1 


1 





1 


1 


19. 


User alerting, no answer 












1 





1 





1 


21. 


Call rejected 


Note 9 - user supplied 




















siagnostic (note 4) 








1 





1 


1 





22. 


Number changed 


New destination (note 5) 








1 


1 





1 





26. 


Non selected user clearing 












1 


1 





1 


1 


27. 


Destination out of order 












1 


1 


1 








28. 


Invalid number format (incomplete 






















number) 












^ 


1 


1 





1 


29. 


Facilitv reiected 


Note 1 










1 


1 


1 


1 





30. 


Response to STATUS ENQUIRY 












1 


1 


1 


1 


1 


31. 


Normal, unspecified 









1 











1 





34. 


No circuit / channel available 









1 








1 


1 





38. 


Network out of order 









1 





1 








1 


41. 


Temporary failure 









1 





1 





1 





42. 


Switching equipment congestion 









1 





1 





1 


1 


43. 


Access information discarded 


Discarded information 




















element identifiers (note 





1 





1 


1 








44. 


Requested circuit / channel 


"1 




















unavailable 









1 





1 


1 


1 


1 


47. 


Resources unavailable, unspecified 









1 


1 











1 


49. 


Quality of service unavailable 


Note 9 







1 


1 








1 





50. 


Requested facility not subscribed 


Note 1 







1 


1 





1 


1 


1 


55. 


Incoming calls barred within the 


Note 1 




















CUG 









1 


1 


1 








1 


57. 


Bearer capability not authorized 


Note 3 







1 


1 


1 





1 





58. 


Bearer capability not presently 


Notes 




















available 









1 


1 


1 


1 


1 


1 


63. 


Service or option not available. 






















unspecified 






1 

















1 


65. 


Bearer service not implemented 


Note 3 




1 











1 








68. 


ACM equal to or greater than ACM 






















max 






1 











1 





1 


69. 


Requested facility not implemented 


Note 1 




1 











1 


1 





70. 


Only restricted digital information 






















bearer capability is available 






1 








1 





1 


1 


75. 


MES to MES CC release 






1 








1 


1 


1 


1 


79. 


Service or option not implemented. 






















unspecified 






1 





1 











1 


81. 


Invalid transaction identifier value 






1 





1 





1 


1 


1 


87. 


User not member of CUG 


Note 1 




1 





1 


1 











88. 


Incompatible destination 


Incompatible parameter 




















(Note 2) 




1 





1 


1 





1 


1 


91. 


Invalid transit network selection 











1 


1 


1 


1 


1 


95. 


Semantical ly incorrect message 

























96. 


Invalid mandatory data 


Information element 




















identifier(s) 




















1 


97. 


Message type non-existent or not 


Message Type 


















implemented 



















1 





98. 


Message type not compatible with 


Message Type 


















protocol state 



















1 


1 


99. 


Information element non-existent or 


Information element 


















not implemented 


identifier(s) (Notes 6,7) 












1 








100. 


Conditional IE error 


Information element 




















identifier(s) (Note 6) 



ETSI 



GMR-2 04.008 



228 



ETSI TS 101 377-4-7 VI. 1.1 (2001-03) 



Cause 




Value 






Cause 


Cause 


Diagnostic 


Remarks 


Class 












num. 








7 6 


5 


4 


3 


2 


1 










1 1 








1 





1 


101. 


Message not compatible with 


Message Type 
















protocol state 






1 1 








1 


1 





102. 


Recovery on timer expiration 


Timer Number (note 8) 


1 1 





1 


1 


1 


1 


111. 


Protocol error, unspecified 






1 1 


1 


1 


1 


1 


1 


127. 


Interworking, unspecified 







All other values in the range to 31 shall be treated as cause 31 . 
All other values In the range 32 to 47 shall be treated as cause 47. 
All other values in the range 48 to 63 shall be treated as cause 63. 
All other values in the range 64 to 79 shall be treated as cause 79. 
All other values in the range 80 to 95 shall be treated as cause 95. 
All other values in the range 96 to 1 1 1 shall be treated as cause 111. 

All other values in the range 1 12 to 127 shall be treated as cause 127. 

NOTE 1: Diagnostics for supplementary services are handled as follows: 
octet 5, bit 8: 

This is an extension bit as defined in the preliminary part of clause 1 1.5. In this version of this 
protocol, this bit shall be set to 1. If it is set to zero, the contents of the following octets shall be 
ignored. 

octet 5, bits 7-1: 

0000001 - Outgoing calls barred within CUG 

0000010 - No CUG selected 

0000011 - Unknown CUG index 

0000100 - CUG index incompatible with requested basic service 

0000101 - CUG call failure, unspecified 
00001 10 - CLIR not subscribed 

All other values shall be ignored. 

NOTE 2: The incompatible parameter is composed of the incompatible information element identifier. 

NOTE 3: The format of the diagnostic field for cause numbers 57, 58 and 65 is as shown in figure 1 1.5.4.4 and 
tables 11.5.4.6 to 11.5.4.13. 

NOTE 4: The user supplied diagnostics field is encoded according to the user specification, subject to the 

maximum length of the cause information element. The coding of user supplied diagnostics should be 
made in such a way that it does not confiict with the coding described in Note 9 below. 

NOTE 5: The new destination is formatted as the called party BCD number information element, including 
information element identifier. 

NOTE 6: Locking and non-locking shift procedures described in clause 11.5.4.2 and 1 1.5.4.3 are applied. In 

principle, information element identifiers are ordered in the same order as the information elements in the 
received message. (Not applicable to current GMR-2 system - details specified are for future use). 

NOTE 7: When only the locking shift information element is included and no information element identifier 

follows, it means that the codeset in the locking shift itself is not implemented. (Not applicable to current 
GMR-2 system - details specified are for future use). 

NOTE 8: The timer number is coded in IAS characters, e.g., T308 is coded as "3" "0" "8". The following coding is 
used in each octet: 

bit 8: spare "0" 

bits 7-1: IAS character 
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Octet 5 carries "3", octet 5a carries "0", etc. 
NOTE 9: The following coding is used for octet 5: 
bit 8: 1 

bits 7-3: 00000 

bits 2-1: condition as follows: 

00 - unknown 

01 - permanent 
10 - transient 

1 1 .5.4.1 1 a CLIR suppression (Not applicable to current GMR-2 system - specified for 
future use) 

The CLIR suppression information element may be sent by the MES to the network in the SETUP message. The use is 
defined in GSM 04.81 [20]. 

The CLIR suppression information element is coded as shown in figure 11.5.4.12. The CLIR suppression is a type 2 
information element. 

8 7 6 5 4 3 2 1 

I I CLIR Suppression lEI ~| octet 1 

Figure 11.5.4.12: CLIR Suppression information Eiement Format 

1 1 .5.4.1 1 b CLIR invocation (Not applicable to current GMR-2 system - specified for 

future use) 

The CLIR invocation information element may be sent by the MES to the network in the SETUP message. The use is 
defined in GSM 04.81 [20]. 

The CLIR invocation information element is coded as shown in figure 11.5.4.13. 

The CLIR invocation is a type 2 information element. 

8 7 6 5 4 3 2 1 

I I CLIR invocation lEI | octet 1 

Figure 11.5.4.13: CLIR Invocation Information Element Format 

1 1 .5.4.12 Congestion level (Not applicable to current GMR-2 system - specified for 
future use) 

The purpose of the congestion level information element is to describe the congestion status of the call. 
The congestion level information element is coded as shown in figure 11.5.4.14 and table 11.5.4.24. 
The congestion level is a type 1 information element. 



8 


7 6 5 


4 


3 2 


1 






Congestion Level 
lEI 


congestion level 


octet 1 



Figure 11.5.4.14: Congestion Level Information Element Format 
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Table 11.5.4.24: Congestion Level Information Element Coding Standard 



Congestion level (octet 1) 
Bits 

4 3 2 1 

receiver ready 

1111 receiver not ready 

All other values are reserved 



1 1 .5.4.13 Connected number (Not applicable to current GMR-2 system - specified for 
future use) 

The purpose of the connected number information element is to identify the connected party of a call. 
The connected number information element is coded as shown in tigure 11.5.4.15. 

The connected number is a type 4 information element with a minimum length of 3 octets and a maximum length of 14 
octets. 



8 


7 6 


5 


4 3 


2 1 




1 Connected Number lEI 


octet 1 


Length of connected number contents 


octet 2 


0/1 


type of 




numbering plan 


octet 3 


ext 


number 




identification 


(note 1) 


1 


presentation 








screening 


octet 3a 


ext 


indicator 




spare 


indicator 


(note 1)* 




Number digit 2 




Number digit 1 


octet 4* 












(note 1) 




Number digit 4 




Number digit 3 


octet 5* 












(note 1) 


(note 2) 







Figure 11.5.4.9: Calling Party BCD Number Information Element Format 

The contents of octets 3, 4, 5, etc., are coded as shown in table 11.5.4.16. The coding of octet 3a is defined in table 
11.5.4.18. 

If the connected number contains an odd number of digits, bits 5 to 8 of the last octet shaU be filled with the end mark 
coded as "1111". 

1 1 .5.4.14 Connected subaddress (Not applicable to current GMR-2 system - specified 
for future use) 

The purpose of the connected subaddress information element is to identify a subaddress associated with the connected 
party of a call. 

The connected subaddress information element is coded as shown in figure 11.5.4.16. 

The connected subaddress is a type 4 information element with a minimum length of 2 octets and a maximum length of 
23 octets. 



ETSI 



GMR-2 04.008 231 ETSI TS 1 01 377-4-7 VI .1 .1 (2001 -03) 



8 


7 6 5 


4 


3 


2 


1 






Calling Party Subaddress lEI 


octet 1 


Length of called party subaddress contents 


octet 2 


0/1 


type of 


odd/even 











octet 3* 


ext 


subaddress 


idicat. 










subaddress information 


octet 4* 



etc. 



Figure 11.5.4.16: Connected Subaddress Information Element Format 

The coding for Type of subaddress, odd/even indicator, and subaddress information is in table 11.5.4.17. 

11.5.4.15 Facility 

The purpose of the facility information element is to transport supplementary service related information. Within the 
scope of the present document, the content of the Facility information field is an array of octets. The usage of this 
transportation mechanism is defined in GSM 04.80 [191. 

The facility information element is coded as shown in figure 1 1.5.4.17. 

The facility is a type 4 information element with a minimum length of 2 octets. No upper length hmit is specified, 
except for that given by the maximum number of octets in a L3 message (see GMR-2 04.006 [15]). 

8 7 6 5 4 3_ 2 1 

I Facility lEI 

Length of facility contents 

Facility information (see GSM 04.80 [19]) 



Figure 11.5.4.17: Facility Information Element Format 

11.5.4.16 High layer compatibility 

The purpose of the high layer compatibility information element is to provide a means which should be used by the 
remote user for compatibility checking. See Annex B. 

The high layer compatibility information element is coded as shown in figure 1 1.5.4. 18 and table 1 1.5.4.25. 

The high layer compatibihty is a type 4 information element with a minimum length of 2 octets and a maximum length 
of 5 octets. 

NOTE 1: The high layer compatibihty information element is transported transparently by a PLMN between a call 
originating entity (e.g., a calling user) and the addressed entity (e.g., a remote user or a high layer 
function network node addressed by the call originating entity). However, if exphcitly requested by the 
user (at subscription time), a network which provides some capabihties to realize teleservices may 
interpret this information to provide a particular service. 



8 


7 6 


5 4 3 


2 1 






High Layer Compatibility lEI 


octet 1 


Length o 


f high layer compatibility contents 


octet 2 


1 

ext 


coding standard 


interpretation 


presentation method 
of protocol profile 


octet 3* 


0/1 
ext 


high layer characteristics identification 


octet 4* 


1 

ext 


extended high layer characteristics 
identification 


octet 4a* 
(note) 



Figure 11.5.4.18: High Layer Compatibility Information Element Format 



octet 1 
octet 2 
octet 
3-?* 
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If the value part of the IE is empty, the IE indicates "not appUcable". 

NOTE 2: Octet 4a may be present, e.g., when octet 4 indicates Maintenance or Management. 

Table 11.5.4.25: High Layer Compatibility Information Element Coding Standard 



Coding standard (octet 3) 

see ITU-T Recommendation Q.931 [43]. 

Interpretation (octet 3) 

see ITU-T Recommendation Q.931 [43]. 

Presentation metliod of protocol profile (octet 3) 
see ITU-T Recommendation Q.931 [43]. 

High layer characteristics identification (octet 4) 
see ITU-T Recommendation Q.931 [43]. 

Extended high layer characteristics identification (octet 4a) 
see ITU-T Recommendation Q.931 [43]. 



1 1 .5.4.1 6.1 Static conditions for tine liigli layer compatibility IE contents 

Either the value part of the IE is empty, or it contains at least octet 3 and 4. 

11.5.4.17 Keypad facility 

The purpose of the keypad facility information element is to convey IA5 characters, e.g., entered by means of a terminal 
keypad. ( see note). 

The keypad facility information element is coded as shown in figure 1 1.5.4. 19. 
The keypad facility is a type 3 information element with 2 octets length. 



8 7 6 5 4 3 2 1 





Keypad facility lEI 




spare 


Keypad information (IA5 character) 



Figure 11.5.4.19: Keypad Facility Information Element Format 

NOTE: In the system, this information element is only used to transfer one DTMF digit (0, 1 ... 9, A, B, C, D, *, 
#) as one IA5 character. 

11.5.4.18 Low layer compatibility 

The purpose of the low layer compatibility information element is to provide a means which should be used for 
compatibility checking by an addressed entity (e.g., a remote user or an interworking unit or a high layer function 
network node addressed by the calling user). The low layer compatibility information element is transferred 
transparently by a Gateway between the call originating entity (e.g., the calling user) and the addressed entity. 

Except for the information element identifier, the low layer compatibility information element is coded as in 
ETS 300 102-1 [59]. 

The low layer compatibility is a type 4 information element with a minimum length of 2 octets and a maximum length 
of 15 octets. 
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Low Layer Compatability I El 



length of the low layer compatability contents 



The following octets are coded 
as described in ETS 300 102-1 [59] 



octet 1 
octet 2 
octet 3 



Figure 11.5.4.20: Low Layer Compatability Information Element Format 

If the value part of the IE is empty, the IE indicates "not appUcable". 



8 



6 



More Data I El 



octet 1 



Figure 11.5.4.21: lUlore Data Information Element Format 

1 1 .5.4.1 9 More data (Not applicable to current GMR-2 system - specified for future use) 

The more data information element is sent by the MES to the Network or to the Network to the MES in a USER 
INFORMATION message. The presence of the more data information element indicates to the destination remote 
user/MES that another USER INFORMATION message will follow containing information belonging to the same 
block. 

The use of the more data information element is not supervised by the network. 
The more data information element is coded as shown in tigure 11.5.4-21. 
The more data is a type 2 information element. 

1 1 .5.4.20 Notification indicator (Not applicable to current GMR-2 system - specified for 
future use) 

The purpose of the notification indicator information element is to indicate information pertaining to a call. 
The notification indicator information element is coded as shown in figure 1 1.5.4.22 and Table 1 1.5.4.26. 
The notification indicator is a type 3 information element with 2 octets length. 

8 7 6 5 4 3 2 1 



More Data I El 



Notification description 



octet 1 
octet 2 



Figure 11.5.4.21: Notification Indicator Information Element Format 
Table 11.5.4.26: Notification Indicator Information Element Coding Standard 



Notification description (octet 2) 




Bits 




7 6 5 4 3 2 1 







user suspended 


1 


user resumed 


1 


bearer change 


All other values are reserved 





1 1 .5.4.21 Progress indicator 

The purpose of the progress indicator information element is to describe an event which has occurred during the Ufe of 
a call. 
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The progress indicator information element is coded as shown in figure 11.5.4.23 and Table 11.5.4.27. 
The progress indicator is a type 4 information element with a length of 4 octets. 



8 7 6 5 4 3 2 1 



1 Progress Indicator lEI 


octet 1 


length of the progress indicator contents 


octet 2 


1 


coding 





Location 


octet 3 


ext 


standard 


spare 






1 

ext 


progress description 


octet 4 



Figure 11.5.4.22: Progress Indicator Information Element Format 
Table 11.5.4.27: Progress Indicator Information Element Coding Standard 



Coding standard (octet 3) 

Bits 

7 6 

Standardised coding, as described in ITU-T Recommendation Q.931 [43]. 

1 Reserved for other international standards. 

1 National standard. 

1 1 Standard defined for the GSM/system PLMNS as described below 

Coding standards other than "1 1 - Standard defined for the GSM/system PLMNS" shall not be 
used if the progress description can be represented with the GSM standardized coding. 

The MES or Network need not support any other coding standard than "1 1 - Standard defined 
for the GSM PLMNS". 

If a progress indicator IE indicating a coding standard not supported by the receiver is received, 
progress description "Unspecific" shall be assumed. 

Location (octet 3) 
Bits 



4 


3 


2 


1 
















User 











1 


Private network serving the local user 








1 





Public network serving the local user 





1 








Public network serving the remote user 





1 





1 


Private network serving the remote user 


1 





1 





Network beyond the interworking point 



All other values are reserved 



NOTE: Depending on the location of the users, the local public network and remote public 
network may be the same network. 

Progress description (octet 4) 
Bits 



7 


6 


5 


4 


3 


2 


1 


No. 






















1 


1. 


Call is not end-to-end PLMN/ISDN, further call 
progress information may be available in-band 

















1 





2. 


Destination address in non-PLMN/ISDN 

















1 


1 


3. 


Origination address in non-PLMN/ISDN 











1 











8. 


In-band information or appropriate pattern now 
3V3.il 3. bio 





1 

















32. 


Call is end-to-end PLMN/ISDN 



All other values Unspecific 



NOTE: Only the value "11" shall be used as the "Coding Standard" value. {GSM standard} 

Only the value "0100" shall be used as the "Location" value. {Public network serving the remote user} 
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1 1 .5.4.22 Repeat indicator 

The purpose of the repeat indicator information element is to indicate how the associated repeated information elements 
shall be interpreted, when included in a message. The repeat indicator information element is included immediately 
before the first occurrence of the associated information element which will be repeated in a message. "Mode 1" refers 
to the frrst occurrence of that information element, "mode 2" refers to the second occurrence of that information element 
in the same message. 

The repeat indicator information element is coded as shown in figure 11.5.4.24 and Table 11.5.4.28. 
The repeat indicator is a type 1 information element. 



8 


7 6 5 


4 


3 2 


1 






Repeat Indicator 
lEI 


repeat indication 


octet 1 



Figure 11.5.4.24: Repeat Indicator Information Element Format 
Table 11.5.4.28: Progress Indicator Information Element Coding Standard 



Repeat indication (octet 1) 
Bits 

4 3 2 1 

1 Circular for successive selection "mode 1 alternate mode 2" 

11 Sequential for successive selection "mode 1 and then mode 2" 

All other values are reserved 



1 1 .5.4.22a Reverse call setup direction 



This information element may be included in a MODIFY and MODIFY COMPLETE message to indicate that the 
direction of the data call to which the MODIFY message relates is opposite to the call setup direction. 

The reverse call setup direction information element is coded as shown in figure 11.5.4.25. 

The reverse call setup direction is a type 2 information element 

8 7 6 5 4 3 2 1 



Reverse Call Setup Direction lEI 



octet 1 



Figure 11.5.4.25: Reverse Call Setup Direction Information Element Format 



11.5.4.23 Signal 

The purpose of the signal information element is to allow the network to convey information to a user regarding tones 
and alerting signals (see clauses 6.2.2.3.2 and 8.3.3). 

The signal information element is coded as shown in figure 11.5.4.26 and Table 11.5.4.29. 
The signal is a type 3 information element with 2 octets length. 

8 7 6 5 4 3 2 1 



Signal lEI 



signal value 



octet 1 
octet 2 



Figure 11.5.4.25: Signal Information Element Format 
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Table 11.5.4.29: Signal Information Element Coding Standard 



Signal value (octet 2) 
Bits 



8 


7 


6 


5 


4 


3 


2 


1 




























dial tone on 























1 


ring back tone on 




















1 





intercept tone on 




















1 


1 


network congestion tone on 

















1 








busy tone on 

















1 





1 


confirm tone on 

















1 


1 





answer tone on 

















1 


1 


1 


call waiting tone on 














1 











off-hook warning tone on 








1 


1 


1 


1 


1 


1 


tones off 





1 








1 


1 


1 


1 


alerting off 



All other values are reserved 



NOTE: Only the following values shall be used: 
"00000001" { intercept tone on} 
"00000111" {call waiting tone on} 



1 1 .5.4.24 SS version indicator 



The purpose of the SS version indicator information element is to aid the decoding of the Facility information element 
as described in GSM 04.10 [17]. Within the scope of the present document, the contents of the SS Version information 
field is an array of one or more octets. The usage of the SS version information field is defined in GSM 04.80 [19]. 

The SS version indicator information element is coded as shown in figure 11.5.4.27. 

The SS version indicator is a type 4 information element with a minimum length of 2 octets. No upper length limit is 
specified except for that given by the maximum number of octets in a L3 message (see GMR-2 04.006 [15]). 



8 



SS Version lEI 



length of SS version indicator contents 



SS version information (see GSIVI 04.80 [1 9]) 



Octet 1 

Octet 2 
Octet 3* 



Figure 11.5.4.27: SS Version Information Element Format 

NOTE: Usually, this information element has only one octet of content. 



1 1 .5.4.25 User-user (Not applicable to current GMR-2 system - specified for future use) 

The purpose of the user-user information element is to convey information between the MES and the remote ISDN user. 

The user-user information element is coded as shown in figure 11.5.4.28 and Table 11.5.4.30. There are no restrictions 
on the content of the user-user information field. 

The User-User is a type 4 information element with a minimum length of 3 octets and a maximum length of either 35 or 
131 octets. In the SETUP, ALERTING, CONNECT, DISCONNECT, RELEASE and RELEASE COMPLETE 
messages, the user-user information element has a maximum size of 35. In USER INFORMATION messages, the user- 
user information element has a maximum size of 13 1 octets. 
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User-user lEI 



octet 1 
octet 2 
octet 3 
octet 4* 



Length of user-user contents 



user-user protocol discriminator 



User-user information 



octet N* 



Figure 11.5.4.27: SS Version Information Element Format 



Table 11.5.4.29: Signal Information Element Coding Standard 



User-user protocol discriminator (octet 3) 



Bits 


















8 


7 


6 


5 


4 


3 


2 


1 




























User specific protocol (Note 1 ) 























1 


OSI high layer protocols 




















1 





X.244 (Note 2) 




















1 


1 


Reserved for system management convergence 


















function 

















1 








IAS characters (Note 3) 

















1 


1 


1 


Rec. V.120 rate adaption 














1 











Q.931 [43] (1.451) user-network call control 


















messages 











1 














Reserved for other network layer or layer 3 










through 








protocols including Rec. X.25 [52] 








1 


1 


1 


1 


1 


1 


(Note 4) 





1 




















Reserved for other network layer or layer 3 










through 








protocols including Rec. X.25 [52] 


1 


1 


1 


1 


1 


1 


1 





(Note 4) 



All other values are reserved 

NOTE 1 : The user information is structured according to user needs. 

NOTE 2: The user information is structured according to Rec.X.244 which specifies the 

structure of X.25 [52] call user data. 
NOTE 3: The user information consists of IAS characters. 

NOTE 4: These values are reserved to discriminate these protocol discriminators from the first 
octet of a X.25 [52] packet including general format identifier. 
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1 2 List of system parameters 



The description of timers in the following tables should be considered a brief summary. The precise details are found in 
clauses 4 through 7, which should be considered the definitive descriptions. 

12.1 Timers 



12.1.1 Timers on the Mobile Eartli Station side 

T3122: This timer is used during random access, after the receipt of an IMMEDIATE ASSIGN REJECT 

message. 

Its value is given by the network in the IMMEDIATE ASSIGN REJECT message. 

T3124: NOT USED 

T3126: This timer is started either: 

after sending the maximum allowed number of CHANNEL REQUEST messages during an 
immediate assigimient procedure; 

or 

on receipt of an IMMEDIATE ASSIGNMENT REJECT message; 
Whichever occurs first. 

It is stopped at receipt of an IMMEDIATE ASSIGNMENT message 
At its expiration, the immediate assignment procedure is aborted. 

The minimum value of this timer is equal to the time taken by T + 2S slots of the MESs S-RACH. 

S and T are defined in clause 4.3.1.2. The maximum value of this timer is 5 seconds. 

T3110: This timer is used to delay the channel deactivation after the receipt of a (fuU) CHANNEL RELEASE. Its 
purpose is to let some time for disconnection of the main signalling link. 

Its value is set to such that the DISC frame is sent twice in case of no answer from the network. 

(It should be chosen to obtain a good probability of normal termination (i.e., no time out of T3109) of 
the channel release procedure.) 

12.1.2 Timers on tine Network side 

T3 1 1 : This timer is started when a channel is allocated with an IMMEDIATE ASSIGNMENT message. It is 
stopped when the MES has correctly seized the channels. 

Its value is network dependent. 

NOTE: It could be higher than the maximum time for a L2 establishment attempt. 

T3103: NOT USED. 

T3105: NOT USED 

T3 107: This timer is started by the sending of an ASSIGNMENT COMMAND message and is normally stopped 
when the MES has correctly seized the new channels. 

Its purpose is to keep the old channel sufficiently long for the MES to be able to return to the old 
channels, and to release the channels if the MES is lost. 
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Its value is network dependent. 

NOTE: It could be higher than the maximum transmission time of the ASSIGNMENT COMMAND message 
plus twice the maximum duration of an attempt to establish a data link multiframe mode. 

T3 109: This timer is started when a lower layer failure is detected by the network, when it is not engaged in a RF 
procedure. It is also used in the channel release procedure. 

Its purpose is to release the channels in case of loss of communication. 

Its value is network dependent. 

Note: Its value should be large enough to ensure that the MES detects a radio link failure. 

T3111: This timer is used to delay the channel deactivation after disconnection of the main signalling link. Its 
purpose is to let some time for possible repetition of the disconnection. 

Its value is equal to the value of T3 1 10. 

T31 13: This timer is started when the network has sent a PAGING REQUEST message and is stopped when the 
network has received the CHANNEL REQUEST message. 

Its value is network dependent. 

NOTE: The value could allow for repetitions of the CHANNEL REQUEST message and the requirements 
associated with T3101. 

12.1.3 Other parameters 

Nyl: NOT USED 



12.2 Timers of Mobility Management 

Table 12.2.1 : Mobility IVIanagement Timers - IVIES side 



TIMER 


MM 


TIMEOUT 


CAUSE FOR START 


NORMAL STOP 


AT THE 


NUM. 


STATE 


VALUE 






EXPIRATION 


T3210 


3 


20 s 


- LOC_UPD_REQ 
sent 


- LOC UPD AGO 

- LOG UPD REJ 

- AUTH_REJ 
Lower layer failure 


Start T321 1 


T3211 


1, 


15s 


- LOC_UPD_REJ with 


Time out 


Restart the Location 




2 




cause #1 7 network 
failure 

lower layer failure 

or 

RR conn, released 
after RR conn. Abort 
during loc. updating 


spotbeam change 
request for MM 
connection 
establishment 
change of LA 


up-date procedure 


T3212 


1, 


Note 


termination of MM 


initiation of MM service 


initiate periodic 




2 




service or MM 
signalling 


or MM signalling 


updating 


T3213 


1, 
2, 
11 


4s 


location up-dating 
failure 


expiry 
- change of S-BCCH 
parameter 


new random attempt 


T3220 


7 


5s 


Reserved 






T3230 


5 


15s 


- CM_SERV_REQ 


Cipher mode setting 

- CM SERV REJ 

- CM_SERV_ACC 


provide release ind. 


T3240 


9, 
10 


10s 


see clause 12.2.1 


clause 12.2.1 


abort the RR 
connection 


NOTE: 


the time-out value is broadcast in a SYSTEM INFORMATION message 
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Table 12.2.2: Mobility Management Timers - Network Side 



TIMER 
NUM. 


MM 
STATE 


TIME 
OUT 
VALUE 


CAUSE FOR START 


NORMAL STOP 


AT THE FIRST 
EXPIRATION 


AT THE 
SECOND 
EXPIRATION 


T3250 


6 


5 s 


Reserved 








T3255 




Note 


LOC_UPD_ACC sent 
with "Follow on Proceed" 


CM SERVICE 
REQUEST 


Release RR 

connection or 
use for mobile 
station 

terminating call 




T3260 


5 


5s 


AUTHENT REQUEST 
sent 


AUTHENT 

RESPONSE 
received 


optionally 

release RR 
connection 




T3270 


4 


5s 


IDENTITY REQUEST 
sent 


IDENTITY 

RESPONSE 

received 


Optionally 
release RR 
connection 




NOTE: The value of this timer is not specified by this recommendation 



12.2.1 Timer T3240 

Timer T3240 is started in the MES when: 

a) The MES receives a LOCATION UPDATING ACCEPT message completing a location updating procedure in 
the cases specified in clauses 5.4.4.6 and 5.4.4.8; 

b) The MES receives a LOCATION UPDATING REJECT message in the cases specified in clause 5.4.4.7; 

c) The MES has sent a CM SERVICE ABORT message as specified in clause 5.5.1.7; 

d) The MES has released or aborted all MM connections in the cases specified in clauses 5.3.2.5, 5.3.5.2, 5.5.1.1, 
and 5.5.3.1. 

Timer T3240 is stopped, reset, and started again at receipt of an MM message. 

Timer T3240 is stopped and reset (but not started) at receipt of a CM message that initiates establishment of an CM 
connection (an appropriate SETUP, REGISTER, or CP-DATA message as defined in the present document, 
GSM 04.10 [17] or GSM 04.11 [18]). 



ETSI 



GMR-2 04.008 241 ETSI TS 1 01 377-4-7 VI .1 .1 (2001 -03) 

12.3 Timers of Circuit-Switched Call Control 



Table 12.3.1 : Call Control Timers - MES Side 



TIM. 
NUM. 


TIM 
VAL 


STATE OF CALL 


CAUSE OF START 


NORMAL 
STOP 


AT FIRST 
FXPIRATION 


AT SECOND 
FXPIRATION 

^y\n Irin 1 lx,/l>l 


1303 


30 s 


CALL INITIATED 


CM SER RQ sent 


CALL PROC, or 
REL COMP 

1 COCI VCTJ 


Clear the call 


Timer is not 
restarted 


1305 


30 s 


Disconnect 
Request 


DISC sent 


REL or DISC 
received 


REL sent 


Timer is not 
restarted 


1 oUo 


oU S 


neiease requesi 


ncL ScilT 


ntL UvJIVIr Or 

REL received 


neirans. 
RELEASE 
restart T308 


oaii rei. 
Release 


1310 
Note 


30 s 


Outgoing call 
Proceeding 


CALL PROC 
received 


ALERT,CONN, 
DISC or PROG 
rec. 


Send DISC 


Timer is not 
restarted 


1313 


30 s 


Connect Request 


CONN sent 


CONNect 

ACKnowledge 
received 


Send DISC 


Timer is not 
restarted 


1323 


30 s 


Modify Request 


MOD sent 


MOD COMP or 
MOD REJ 
received 


Clear the call 


Timer is not 
restarted 


NOTE: 131 is not started if progress indicator #1 or #2 has been delivered in the CALL PROCEEDING message or 
in a previous PROGRESS message. 



Table 12.3.2: Call Control Timers - Network Side 



TIM. 
NUM. 


DFT 
TIM 
VAL 


STATE OF 
CALL 


CAUSE OF START 


NORMAL 
STOP 


AT FIRST 
EXPIRATION 


AT SECOND 
EXPIRATION 


T301 
Note 1 


Min 

180 s 


Call received 


ALERT received 


CONN received 


Clear the call 


Timer is not 

restarted 


T303 


Note 2 
15s 


Call present 


SETUP sent 


CALL CONF or 
REL COMP 
received 


Clear the call 


Timer is not 
restarted 


T305 


30 s 


Disconnect 
Indication 


DISC without 
progress indie. #8 
sent 


REL or DISC 
received 


Network sends 
RELEASE 


Timer is not 
restarted 


T306 


30 s 


Disconnect 
Indication 


DISC with progress 
indie. #8 sent 


REL or DISC 
received 


Stop the tone/ 
announc. Send 
REL 


Timer is not 
restarted 


T308 


Note 2 
15s 


Release request 


REL sent 


REL COMP or 
REL received 


Retrans 
RELEASE 
restart T308 


Release call 
reference 


T310 


Note 2 
25 s 


Incoming call 
proceeding 


CALL CONF 
received 


ALERT, CONN 
or DISC 
received 


Clear the call 


Timer is not 
restarted 


T313 


Note 2 
15s 


Connect 
Indication 


CON sent 


CON ACK 
received 


Clear the call 


Timer is not 
restarted 


T322 


5s 


See clause 
6.5.3.1 










T323 


30 s 


Modify request 


MOD sent 


MOD COMP or 
MOD REJ 

received 


Clear the call 


Timer is not 
restarted 


NOTE 1 : The networl< may already have applied an internal alerting supervision function, e.g., incorporated within call 

control. If such a function is known to be operating on the call, then timer T301 is not used. 
NOTE 2: These time values are set by the network operator. 

General: The MSC starts on MM connection establishment a timer for 1 0s (0CT1 ) while it waits for the reception of 
the SETUP message. 
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Annex A (informative): 

Example of subaddress information element coding 

This annex gives an example of how the Called Party Subaddress IE is encoded to carry subaddress digits that use IA5 
characters. This example is also applicable to the Calling Party Subaddress IE. 



8 


7 


6 


5 


4 


3 


2 


1 







1 


1 





1 


1 





1 


octet 1 








Called Party Subaddress lEI 























1 


1 


1 


octet 2 








Length 










1 











X 











octet 3 


not 




NASP 




odd/even 










ext 


(X.213/ISO 8348 AD2 [33]) 


Note 1 




Note 2 









1 





1 














octet 4 








API (Note 3) 










IA5 Character (Note 4) 


octet 5 


IA5 Character (Note 4) 


octet 6 







IA5 Character (Note 4) 



octet 9 
(Note 5) 



NOTE 1: The value of this bit has no signiiicance when the type of subaddress is NSAP". 
NOTE 2: These bits are spare. 

NOTE 3: The Authority and Format Identiiier code 50 (in BCD) indicates that the subaddress consists of IA5 
characters (see ISO standard 8348 AD2 [33]). 

NOTE 4: IA5 character as defined in ITU-T Recommendation T.50 [42]/ISO 646 [31] and then encoded into two 
semi-octets according to the "preferred binary encoding" defined in X.213/ISO 8348 AD2 [33]. (Each 
character is converted into a number in the range 32 to 127 using the ISO 646 [3 1 ] encoding with zero 
parity and the parity bit in the most significant position. This number is then reduced by 32 to give a new 
number in the range to 95. The new number is then treated as a pair of decimal digits with the value of 
each digit being encoded in a semi-octet.) 

NOTE 5: The number of IA5 characters in the subaddress may vary, subject to an upper hmit of 19 IA5 characters. 
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Annex B (normative): 
Compatibility Checl<ing 

B.1 Introduction 

This annex describes the various compatibility checks which shall be carried out to ensure that the best matched MES 
and network capabilities are achieved on a call between a Gateway and the ISDN. 

Three different processes of compatibility checking shall be performed: 

a) At the user-to-network interface on the calling side (see clause B.2); 

b) At the network-user interface on the called side (see clause B.3.2); 

c) User-to-user (see clause B 3.3). 

NOTE: In this context, and throughout this annex, the term "called user" is the end point entity which is expUcitly 
addressed. 

For details on the coding of the information required for compatibility checking, see Annex C. 

B.2 Calling Side Compatibility Checking 

B.2.1 Compatibility Checking of the CM SERVICE REQUEST 
Message 

The network shall check if the service requested in the CM SERVICE REQUEST message is permitted for that 
subscriber. 

B.2.2 Compatibility Subscription Checking of the SETUP 
Message 

At the calhng side, the network shall check that the basic service(s) requested by the calling MES in the Bearer 
CapabiUty information element(s) match(es) with the basic services provided to that subscriber by the Gateway. If for at 
least one bearer capability information element contained in the SETUP message a mismatch is detected, then the 
network shall proceed as follows: 

a) If the SETUP message contained two bearer capabihty information elements for only one of which a mismatch is 
detected, the network shall either: 

i) Under the conditions specified in GSM 07.01 [28], accept the SETUP message with a CALL PROCEEDING 
message containing the, possibly negotiated, bearer capability information element for which no mismatch is 
detected; 

ii) Reject the call using one of the causes listed in Annex H. 

b) Otherwise the network shall reject the call using one of the causes listed in Annex H. 

Network services are described in GMR-2 02.002 [2] and GMR-2 02.003 [3] as bearer services and teleservices, 
respectively. 
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B.3 Called Side Compatibility Checking 

In this clause, the word "check" means that the MES examines the contents of the specified information element. 

B.3.1 Compatibility Checking with Addressing Information 

If an incoming SETUP message is offered to the MES with addressing information (i.e., sub-address or called party 
number), the following shall occur: 

a) If the MES has a DDI number or a sub-address, then the information in any Called Party BCD Number or any 
Called Party subaddress information elements of the incoming SETUP message shall be checked by the MES 
against the corresponding part of the number assigned to the user (e.g., for DDI) or the user's own sub-address. 

In the cases of a mismatch, the MES shall release the call. In the case of a match, the compatibility checking 
described in clauses B.3.2 and B.3.3 shall be performed. 

b) If the MES has no DDI number and no sub-address, then the Called Party BCD Number and Called Party 
subaddress information element shall be ignored for the purposes of compatibility checking. The compatibility 
checking described in clauses B.3.2 and B.3.3 shall be performed. 

NOTE: According to the user's requirements, compatibility checking can be performed in various ways from the 
viewpoint of execution order and information to be checked, e.g., first DDI number/sub-address and then 
bearer capabihty or vice versa. 

B.3.2 Network-to-MES Compatibility Checking 

When the network is providing a basic service at the called side, the MES shall check that the basic service(s) offered 
by the network in the Bearer Capability information element(s) match(es) the basic services that the MES is able to 
support. If a mismatch is detected, then the MES shall proceed as follows: 

a) If the SETUP message contained two bearer capability information elements for only one of which a mismatch is 
detected, the MES shall either: 

i) Under the conditions specified in GSM 07.01 [28], accept the SETUP message with a CALL CONFIRMED 
message containing the, possibly negotiated, bearer capability information element for which no mismatch is 
detected; 

ii) Reject the call using cause No. 88 "incompatible destination" 

b) Otherwise the MES shall reject the offered call using a RELEASE COMPLETE message with cause No. 88 
"incompatible destination". 

When interworking with existing networks, limitations in network or distant user signalling (e.g., in the case of an 
incoming call from a PSTN or a call from an analogue terminal) may restrict the information available to the called 
MES in the incoming SETUP message (e.g., missing Bearer Capabihty Information Element or missing High Layer 
Compatibility Information Element). For compatibility checking, and handling of such calls see GSM 07.01 [28]. 

B.3.3 User-to-User Compatibility Checking 

See GSM 07.01 [28]. 



B.4 High Layer Connpatibility Checking 

See GSM 07.01 [28]. 
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Annex C (normative): 

Low layer information coding principles 

C.1 Purpose 

This annex describes principles that shall be used when the calling MES specifies information during call setup 
regarding low layer capabilities required in the network and by the destination terminal. Refer also to GSM 07.01 [28]. 

NOTE: In this context, and throughout this annex, the term "called user" is the end point entity which is exphcitly 
addressed. This may also be an explicitly addressed interworking unit (IWU) (see ITU-T 
Recommendation I.500-Series Recommendations and ITU-T Recommendation X.31 [55] case a). 



C.2 Principles 

C.2.1 Definition of Types of Information 

There are three different types of information that the calling user may specify during call setup to identify low layer 
capabilities needed in the network and in the destination terminal: 

a) Type I information is information about the calling terminal which is only used at the destination end to allow a 
decision regarding terminal compatibihty. An example would be the user information layer 3 protocol. Type I 
information is encoded in octets 5 to 7 of the low layer compatibihty information element; 

b) Type II information is only used by the network to which the calling user is connected for selection of specific 
network resources, e.g., channel type or specific functionality within the interworking function (IWF, see 
GSM 09.07 [30]). This type of information is always present. An example is the coimection element. Type n 
information is coded in: 

i) Octet 3 of the bearer capability information element when the information transfer capabiUty required by the 
calling user is speech; 

ii) Octets 3, 4, 5, and optionally octet 7 of the bearer capabihty information element when the information 
transfer capability required by the calling user is not speech; 

c) Type III information is required for selection of a basic service from the choice of basic services offered by the 
network and together with type II information for selection of an appropriate interworking function (IWF, see 
GSM 09.07 [30]), as well as for terminal compatibihty checking at the destination terminal. An example is the 
information transfer capability. Type 111 information is always present and is encoded in: 

i) Octet 3 of the bearer capability information element when the information transfer capability required by the 
calling user is speech; 

ii) Octets 3, 5, 6, 6a, 6b and 6c of the bearer capabihty information element when the information transfer 
capability required by the calling user is not speech. 

C.2. 2 Examination by Network 

Type I information is user-to-user (i.e., at the calling side not examined by network) while type n and 111 information 
should be available for examination by the destination user and the network. 

NOTE: In the case of a mobile terminated call, if the type II and type 111 information is not sufficient for the 
selection of an appropriate interworking function, the type I information will also examined by the 
network. 
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C.2.3 Location of Type I Information 

Type I information (i.e., terminal information only significant to the called user) shall, when used, be included in the 
low layer compatibiUty information element. 

C.2.4 Location of Types II and III Information 

Type n information is included in the bearer capability information element. Type HI information is also included in the 
bearer capability information element. The network may use and modify type 111 information (e.g., to provide 

interworking). 

In any case, a modification of the bearer capabihty information element has to be performed when interworking to the 
fixed network (e.g., ISDN) is required, where the signalling of the radio interface has to be mapped to fixed network 
signalling (e.g., mapping of GSM BCIE to ISDN BCIE, see GSM 09.07 [30]). 

C.2.5 Relationship Between Bearer Capability and Low Layer 
Compatibility Information Elements 

There shall be no contradiction of information between the low layer compatibility and the bearer capability at the 
originating side. However, as some bearer capabihty code points may be modified during the transport of the call (e.g., 
by the interworking function). This principle imphes that there should be minimal duplication of information between 
the bearer capability information element and the low layer compatibiUty information element. 

NOTE: If as a result of duplication, a contradiction occurs at the terminating side between the bearer capability 
information element and the low layer compatibility information element at the terminating side, the 
receiving entity shall ignore the conflicting information in the low layer compatibiUty information 
element. 
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Annex D (informative): 

Examples of bearer capability information element coding 

This annex does not apply to the GMR-2 system. 
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Annex E (informative): 

Comparison between call control procedures specified in 
GMR-2 04.008 and ITU-T Recommendation Q.931 

This annex does not apply to the GMR-2 system. 
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Annex F (informative): 

Specific cause values for Radio Resource Management 

Cause value = Normal event: 

indicates that the channel is released because of a normal event or that an assignment or handover is successfully, 
and normally, completed. 

Cause value = 1 Abnormal release, unspecified: 

indicates that the channel is released because of an abnormal event without specifying further reasons. 
Cause value = 2 Abnormal release, channel unacceptable: 

indicates that the channel type or channel characteristics are not acceptable. 
Cause value = 3 Abnormal release, timer expired: 

indicates that the release is caused by a timer expiration. 
Cause value = 4 Abnormal release, no activity on the radio path: 

indicates that some supervisory function has detected that the channel is not active. 
Cause value = 5 Preemptive release: 

indicates that the channel is released in order to be allocated to a call with priority (e.g., an emergency call). 

Cause value = 8 Local Transmit Disable: 

Indicates the network has issued a MES Transmit Disable in response to a local interference complaint from another 
system operating in the same frequency band. 

Cause value = 9 Channel mode unacceptable: 

indicates that the MES does not have the capabiUty to handle the requested mode or type of channel 
Cause value = 10 Frequency not implements: 

indicates that the MES does not have the capabiUty to operate on (at least one of) the requested frequency(ies). 

Cause value = 65 Call already cleared: 

indicates that a handover is unsuccessful because the connection has been released by the network or the remote 
user. 

Cause value = 95 Semantically incorrect message: 

See Annex H, clause H5.10. 
Cause value = 96 Invalid mandatory information: 

See Aimex H, clause H6.1. 
Cause value = 97 Message type nonexistent or not implemented: 

See Annex H, clause H6.2. 
Cause value = 98 Message type not compatible with protocol state: 

See Aimex H, clause H6.3. 
Cause value = 100 Conditional IE error: 

See Annex H, clause H6.5. 
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Cause value = 101 No spotbeam allocation available: 

indicates that an assignment or handover is unsuccessful because the MES has no current CA. 
Cause value =111 Protocol error unspecified: 

See Annex H, clause H6.8. 
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Annex G (Informative): 

Specific cause values for Mobility Management 

G.1 Causes Related to Mobile Earth Station Identification 

Cause value = 2 IMSI unknown in HLR: 

This cause is sent to the MES if the MES is not known (registered) in the HLR. 

Cause value = 3 Illegal MES: 

This cause is sent to the MES when the network refuses service to the MES either because an identity of the MES is 
not acceptable to the network or because the MES does not pass the authentication check, i.e., the SRES received 
from the MES is different from that generated by the network. 

Cause value = 4 IMSI unknown in VLR: 

This cause is sent to the MES when the given IMSI is not known at the VLR. 
Cause value = 5 IMEl not accepted: 

This cause is sent to the MES if the network does not accept emergency call establishment using an IMEl. 
Cause value = 6 Illegal ME-MES: 

This cause is sent to the MES if the ME-MES used is not acceptable to the network, e.g., blacklisted. 

G.2 Causes Related to Subscription Options 

Cause value = 8 Local Transmit Disable: 

This cause is sent to the MES when the network receives a request to Umit MES transmissions at a selected location to 
limit interference into other systems operating in the same frequency band. 

Cause value =11 PLMN not allowed: 

This cause is sent to the MES if it requests location updating in a PLMN where the MES, by subscription or due to 
operator determined barring, is not allowed to operate. 

Cause value = 12 Location Area not allowed: 

This cause is sent to the MES if it requests location updating in a location area where the MES, by subscription, is 
not allowed to operate. 

Cause value = 13 National roaming not allowed in this location area: 

This cause is sent to an MES which requests location updating in a location area of a PLMN which offers national 
roaming to that MES, but not in that specific location area. 
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G.3 Causes Related to PLMN Specific Network Failures 
and Congestion 

Cause value = 17 Network failure: 

This cause is sent to the MES if the MSG cannot service an MES generated request because of PLMN failures, e.g. 
problems in MAP. 

Cause value = 22 Congestion: 

This cause is sent if the service request cannot be actioned because of congestion (e.g., no channel, facility 
busy/congested etc.). 

G.4 Causes Related to Nature of Request 

Cause value = 32 Service option not supported: 

This cause is sent when the MES requests a service/facility in the CM SERVICE REQUEST message which is not 
supported by the PLMN. 

Cause value = 33 Requested service option not subscribed: 

This cause is sent when the MES requests a service option for which it has no subscription. 

Cause value = 34 Service option temporarily out of order: 

This cause is sent when the MSC cannot service the request because of temporary outage of one or more functions 
required for supporting the service. 

Cause value = 38 Call cannot be identified: 

This cause is sent when the network cannot identify the call associated with a call re-establishment request. 

G.5 Causes Related to Invalid Messages 

Cause value = 95 Semantically incorrect message: 

See Annex H, clause H.5.10. 
Cause value = 96 Invalid mandatory information: 

See Aimex H, clause H.6.1. 
Cause value = 97 Message type non-existent or not implemented: 

See Aimex H, clause H.6.2. 
Cause value = 98 Message not compatible with protocol state: 

See Aimex H, clause H.6.3. 
Cause value = 99 Information element non-existent or not implemented: 

See Annex H, clause H.6.4. 
Cause value = 100 Conditional IE error: 

See Aimex H, clause H.6.5. 



ETSI 



GMR-2 04.008 253 ETSI TS 1 01 377-4-7 V1 .1 .1 (2001 -03) 

Cause value = 101 Message not compatible with protocol state: 

See Annex H, clause H.6.6. 
Cause value =111 Protocol error, unspecified: 

See Annex H, clause H.6.8. 
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Annex H (informative): 

Specific cause values for Call Control 

H.1 Normal Class 

H.1.1 Cause No. 1 "Unassigned (Unallocated) Number" 

This cause indicates that the destination requested by the User Terminal cannot be reached because, although the 
number is in a valid format, it is not currently assigned (allocated). 

H.1 .2 Cause No. 3 "No Route To Destination" 

This cause indicates that the called user cannot be reached because the network through which the call has been routed 
does not serve the destination desired. 

H.1 .3 Cause No. 6 "Channel Unacceptable" 

This cause indicates the channel most recently identified is not acceptable to the sending entity for use in this call. 

H.1 .4 Cause No. 8 "Operator Determined Barring" 

This cause indicates that the MES has tried to access a service that the MESs network operator or service provider is not 
prepared to allow. 

H.1. 5 Cause No. 16 "Normal Call Clearing" 

This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call 
be cleared. 

Under normal situations, the source of this cause is not the network. 

H.1. 6 Cause No. 17 "User Busy" 

This cause is used when the called user has indicated the inability to accept another call. 
It is noted that the user equipment is compatible with the call. 

H.1. 7 Cause No. 18 "No User Responding" 

This cause is used when a user does not respond to a call establishment message with either an alerting or connect 
indication within the prescribed period of time allocated (delined by the expiration of either timer T303 or T310). 

H.1 .8 Cause No. 19 "User Alerting, No Answer" 

This cause is used when a user has provided an alerting indication but has not provided a connect indication within a 
prescribed period of time. 
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H.1 .9 Cause No. 21 "Call Rejected" 

This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have 
accepted the call because the equipment sending this cause is neither busy nor incompatible. 

H. 1 . 1 Cause No. 22 "Number Changed" 

This cause is returned to a calling MES when the called party number indicated by the calling MES is no longer 
assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support 
this capabihty, cause No. 1 "unassigned (unallocated) number" shall be used. 

H.1 .1 1 Cause No. 26 "Non-Selected User Clearing" 

Not supported. Treated as cause no. 31. 

H.1 .12 Cause No. 27 "Destination Out Of Order" 

This cause indicates that the destination indicated by the MES cannot be reached because the interface to the destination 
is not functioning correctly. The term "not functioning correctly" indicates that a signalhng message was unable to be 
delivered to the remote user, e.g., a physical layer or data link layer failure at the remote user, user equipment off-line, 
etc. 

H.1. 13 Cause No. 28 "Invalid Number Format (Incomplete 
Number)" 

This cause indicates that the called user cannot be reached because the called party number is not a valid format or is 
not complete. 

H.1 .14 Cause No. 29 "Facility Rejected" 

This cause is returned when a facility requested by user can not be provided by the network. 

H.1. 15 Cause No. 30 "Response To STATUS ENQUIRY" 

This cause is included in STATUS messages if the message is sent in response to a STATUS ENQUIRY message. See 
also clause 6.5.3. 

H.1. 16 Cause No. 31 "Normal, Unspecified" 

This cause is used to report a normal event only when no other cause in the normal class applies. 

H.2 Resource Unavailable Class 

H.2.1 Cause No. 34 "No Circuit/Channel Available" 

This cause indicates that there is no appropriate circuit/chaimel presently available to handle the caU. 
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H.2.2 Cause No. 38 "Network Out of Order" 

This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long 
period of time; e.g., immediately re-attempting the call is not likely to be successful. 

H.2.3 Cause No. 41 "Temporary Failure" 

This cause indicates that the network is not functioning correctly and that the condition is not Ukely to last a long period 
of time, e.g., the MES may wish to try another call attempt almost immediately. 

H.2.4 Cause No. 42 "Switching Equipment Congestion" 

This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic. 

H.2.5 Cause No. 43 "Access Information Discarded" 

This cause indicates that the network could not deliver access information to the remote user as requested, i.e., a user- 
to-user information, low layer compatibility, high layer compatibility, or sub-address as indicated in the diagnostic. 

It is noted that the particular type of access information discarded is optionally included in the diagnostic. 

H.2.6 Cause No. 44 "Requested Circuit/Channel Not Available" 

This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other 
side of the interface. 

H.2.7 Cause No. 47 "Resource Unavailable, Unspecified" 

This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class 
applies. 

H.3 Service or Option Not Available Glass 
H.3.1 Cause No. 49 "Quality of Service Unavailable" 

This cause indicates to the User Terminal that the requested quaUty of service, as defined in 
ITU-T Recommendation X.21 [51], cannot be provided. 

H.3.2 Cause No. 50 "Requested Facility Not Subscribed" 

This cause indicates that the requested supplementary service could not be provided by the network because the user 
has no completed the necessary administrative arrangements wdth its supporting networks. 

H.3.3 Cause No. 55 "Incoming Calls Barred within the CUG" 

This cause indicates that although the called party is a member of the CUG for the incoming CUG call, incoming calls 
are not allowed within this CUG. 
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H.3.4 Cause No. 57 "Bearer Capability Not Authorized" 

This cause indicates that the MES has requested a bearer capability which is implemented by the equipment which 
generated this cause but the MES is not authorized to use. 

H.3.5 Cause No. 58 "Bearer Capability Not Presently Available" 

This cause indicates that the MES has requested a bearer capability which is implemented by the equipment which 
generated this cause but which is not available at this time. 

H.3.6 Cause No. 63 "Service or Option Not Available, 
Unspecified" 

This cause is used to report a service or option not available event only when no other cause in the service or option not 
available class apphes. 

H.3.7 Cause No. 68 "ACM Equal To or Greater Than ACMmax" 

This cause is used by the mobile to indicate that call clearing is due to ACM being greater than or equal to ACMmax. 

H.4 Service or Option Not Innplennented Class 
H.4.1 Cause No. 65 "Bearer Service Not Implemented" 

This cause indicates that the equipment sending this cause does not support the bearer capability requested. 

H.4.2 Cause No. 69 "Requested Facility Not Implemented" 

This cause indicates that the equipment sending this cause does not support the requested supplementary service. 

H.4. 3 Cause No. 70 "Only Restricted Digital Information Bearer 
Capability Is Available" 

This cause indicates that one equipment has requested an unrestricted bearer service, but that the equipment sending this 
cause only supports the restricted version of the requested bearer capability. 

H.4. 4 Cause No. 79 "Service or Option Not Implemented, 
Unspecified" 

This cause is used to report a service or option not implemented event only when no other cause in the service or option 
not implemented class apphes. 
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H.5 Invalid Message (e.g., Parameter Out of Range) 
Class 

H.5.1 Cause No. 81 "Invalid Transaction Identifier Value" 

This cause indicates that the equipment sending this cause has received a message with a transaction identifier which is 
not currently in use on the MES-Network interface. 

H.5.2 Cause No. 87 "User Not Member of CUG" 

This cause indicates that the called user for the incoming CUG call is not a member of the specified CUG. 

H.5.3 Cause No. 88 "Incompatible Destination" 

This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer 
compatibility, high layer compatibility, or other compatibility attributes (e.g., data rate) which cannot be 
accommodated. 

H.5.4 Cause No. 91 "Invalid Transit Network Selection" 

For further study. Treated as cause no. 95. 

H.5.5 Cause No. 95 "Semantically Incorrect Message 

This cause is used to report receipt of a message with semantically incorrect contents (see clause 9.8). 

H.6 Protocol Error (e.g., Unknown Message) Class 
H.6.1 Cause No. 96 "Invalid Mandatory Information" 

This cause indicates that the equipment sending this cause has received a message with a non- semantical mandatory IE 
error (see clause 9.5). 

H.6.2 Cause No. 97 "Message Type Non-Existent or Not 
Implemented" 

This cause indicates that the equipment sending this cause has received a message with a message type it does not 
recognize either because this is a message not defined, or defined but not implemented by the equipment sending this 
cause. 

H.6.3 Cause No. 98 "Message Type Not Compatible With 
Protocol State" 

This cause indicates that the equipment sending this cause has received a message not compatible with the protocol 
state (see clause 9.4). 
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H.6.4 Cause No. 99 "Information Element Non-Existent or Not 
Implemented" 

This cause indicates that the equipment sending this cause has received a message which includes infonnation elements 
not recognized because the information element identifier is not defined or it is defined but not implemented by the 
equipment sending the cause. However, the information element is not required to be present in the message in order for 
the equipment sending the cause to process the message. 

H.6.5 Cause No. 100 "Conditional IE Error" 

This cause indicates that the equipment sending this cause has received a message with conditional IE errors (see clause 
9.7.2). 

H.6.6 Cause No. 101 "IVIessage Not Compatible With Protocol 
State" 

This cause indicates that a message has been received which is incompatible with the protocol state or that a STATUS 
message has been received indicating an incompatible call state. 

H.6.7 Cause No. 102 "Recovery On Timer Expiry" 

This cause indicates that a procedure has been initiated by the expiration of a timer in association with GMR-2 error 
handling procedures. 

H.6.8 Cause No. 1 1 1 "Protocol Error, Unspecified" 

This cause is used to report a protocol error event only when no other cause in the protocol error class appUes. 



H.7 Interworking Class 

H.7.1 Cause No. 127 "Interworking, Unspecified" 

This cause indicates that there has been interworking with a network which does not provide causes for actions it takes; 
thus, the precise cause for a message which is being sent cannot be ascertained. 
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